[Pkg-e-devel] More updates

[Ross Vandegrift]

On 03/27/2016 04:28 PM, Martinx - ジェームズ wrote:
> Are you using the following git repos?
> 
> https://github.com/rvandegrift/efl.git
> https://github.com/rvandegrift/evas_generic_loaders.git
> https://github.com/rvandegrift/emotion_generic_players.git
> https://github.com/rvandegrift/elementary.git
> https://github.com/rvandegrift/e.git
> https://github.com/rvandegrift/terminology.git 

Yes, those are correct.

> I would like to invest sometime this week to build it for Ubuntu Xenial
> and Debian SID.

You should be able to run "gbp buildpackage" from a cloned copy.  If you
use git-pbuilder, add --git-pbuilder.  I haven't tried Ubuntu, but I
guess it will probably work.

> BTW, I'm seeing that those repositories contains both Enlightenment
> code, and the "debian/" subdir. Can we create independent Git repos only
> for the "debian/" subdirs? Similar with MATE, look:
> 
> https://github.com/mate-desktop/debian-packages
> 
> And, of course, fully integrated with "git-buildpackage"... Let me know
> what do you think...

No, in my current process, the Enlightenment code and debian/ files are
both required.  I'm not using upstream tarball releases, so
git-buildpackage needs the upstream sources & tags to generate the
.orig.tar.gz file.

Here are the reasons I prefer this organization:
1) The resources for a source package are generated from a single repo
2) Builds can be completed automated
3) Many steps of new releases can be automated
3) No need to write/maintain any build scripts, just packaging & config
4) Upstream patches are very easy to find and import since upstream git
is already present.

There are some disadvantages too though:
1) More data to download/store on my workstation
2) some old/inconsistent git-buildpackage docs on the web
3) New releases can conflict with old releases in a way that tarballs
avoid (see README.source)

To me, the advantages outweigh the disadvantages.

Ross