... 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 [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
