Packaging for Debian/Ubuntu

[Ivan Vučica]

Yes, I've read the disappointing recommendations that upstream shouldn't include the debian/ directory. It's as if they're discouraging production of packages by upstream. It would mean less effort for themselves. I wonder why their recommendation stands?

Anyway, considering the large amount of steps, that may be the reason why the packages end up being out of date. Hence it may make more sense to update gnustep-make to create source packages for itself, as well as all other packages. Also, it may make more sense to integrate (part of) patches upstream, or at least minimize their amount and store them in the repository so they can be applied automatically during creation of source packages.

As the process seems quite involved, can you produce a short .sh script that can be easily run to produce the gnustep-make binary?

Also, as I may have mentioned, what I've committed some time in October (I think) allows us to produce binary packages that aren't up to Debian's standards, but work okay. (They only lack dependencies.) Simply type "make deb" to see what happens. Of course, it'd be preferable if we'd produce source as opposed to binary packages that could also satisfy Debian developers.

What do you think? Interested in letting us easily produce packages for both currently supported applications, as well as any currently unpackaged ones, such as the ones in GAP?

On Thu Dec 26 2013 at 19:30:24, Markus Hitter <mah@jump-ing.de> wrote:

> ... so I took the plunge and finally managed to upload a recent version
> of gnustep-make to my Ubuntu PPA:
>
> https://launchpad.net/~mah-jump-ing/+archive/ppa
>
> Now waiting for the upload to appear there, this apparently takes
> several hours.
>
> Not unexpected, available documentation about packaging is very
> confusing, it's more like a puzzle to solve. Also, Debian guys (I had to
> join their mentors list and ask to find the way), have a quite different
> idea on how such stuff should work. For example, it's either not
> possible or strongly disencouraged to simply upload sources to form a
> package. Putting packaging information into a developer repository is
> unwanted. They talk a lot about finding "mentors" and "sponsors", think
> solely in terms of "releases" (just tagging a commit to make a release
> is disencouraged as well) and are apparently proud when packaging
> doesn't integrate well into the usual development processes. Oh well.
>
>
> Anyways. They did help, thanks a lot to them. Please find a 10-step list
> with script snippets later in this email. I'd expect these snippets to
> work for all the other packages approximately the same way, gnustep-make
> is just a test ballon.
>
> The question here is, can/should such an effort be done by GNUstep?
> There could be a GNUstep Developers or GNUstep Maintainers group on
> Launchpad to put a bit emphasis into this effort. Even with Debian
> people not liking weekly packaging, it can be done anyways.
>
> Another one is wether these patches attached to the package (6 simple
> ones in the case of gnustep-make) should go into GNUsteps bug tracker to
> be solved upstream ("upstream" = GNUsteps SVN repo). I think this would
> be a good idea.
>
> Last not least, thanks a ton to Yavor Doganov and Gürkan Sengün. They
> made the packages which exist already and updating their work is 10
> times easier than creating packages from scratch.
>
>
> Markus
>
> - - -
> Here's the 10-step list, steps 7a to 7e can require manual interaction:
> - - -
>
> 0) git clone / svn checkout http://svn.gna.org ... ... && cd make
>
> 1) Source packages are not to be confused with binary packages. Source
> packages typically produce more than one binary package. Source packages
> reflect what's in the upstream source code repository. We work with
> source packages here.
>
> 2) To find out which source package is needed, do a dry run for one of
> the binary packages:
>
>   PKG_NAME=gnustep-make-doc
>   apt-get -s source ${PKG_NAME} | tee /tmp/$$
>   if grep -q "Picking" /tmp/$$; then
>     PKG_NAME=$(awk '/^Picking/ { print substr($2, 2, length($2) - 2); }'
> < /tmp/$$)
>   fi
>   rm -f /tmp/$$
>
> 3) Packages have to be built locally before uploading.
>
> 4) Package builds happen against a previous package, so let's fetch this:
>
>   (cd .. && apt-get source ${PKG_NAME})
>
> 5) The first step is to grab debian/ from the older package and moving
> it to the new bunch of sources.
>
>   rm -rf debian
>   tar -xvzf ../${PKG_NAME}*debian.tar.gz
>
> 6) Then add a changelog entry with "dch". Important, because debuild
> grabs the version information from here. Also, the version number is
> used for sorting packages by age:
>
>   . Version
>   dch -v "${GNUSTEP_MAKE_VERSION}-$(date +%Y%m%d)" -D saucy "Weekly
> snapshot."
>
> "Version" is a file provided by GNUstep, "saucy" is the distribution you
> want to build against. Make also sure your name there matches what the
> OpenPGP/GPG tool expects, debuild will look into here.
>
> 7) That done, "quilt" is the tool to maintain the package-side series of
> patches in debian/patches. Good tutorial here:
>
> http://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
>
> Patches are applied one by one until all are done.
>
> 7a) Do "quilt push" to apply a patch. If needed, "quilt pop" reverses this.
>
> 7b) If a patch reports "offset" or "fuzz", also do a "quilt refresh".
> This updates the patch to the new sources.
>
> 7c) If a patch became obsolete, delete it with "quilt delete -r"
>
> 7d) If a patch no longer applies but is still needed, fix it manually by
> editing source files, then do a "quilt refresh".
>
> 7e) If there's need for an additional patch, edit the sources, then
> record the patch with "quilt new <patch name>". Wether an additional
> patch is required is found out by building, installing and testing the
> package, so you want to return here in case results aren't satisfying.
>
> 8) Now it's a good time to change debian/control (and debian/control.in,
> which should eventually go away) and/or debian/rules.
>
> 9) Tar these upstream sources up (sort of tar-yourself-up), but only in
> the unpatched state:
>
>   quilt pop -a
>   export TAR_DIR=$(basename "${PWD}") && \
>     (cd .. && \
>      tar -cvzf ${PKG_NAME}_${GNUSTEP_MAKE_VERSION}.orig.tar.gz \
>          --exclude .git --exclude .pc "${TAR_DIR}") && \
>     unset TAR_DIR
>   quilt push -a
>   debuild -S -sd
>
> 10) Upload the package:
>
>   dput ppa:mah-jump-ing/ppa ../${PKG_NAME}*.changes
>
>
> --
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.reprap-diy.com/
> http://www.jump-ing.de/
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep