On Wed, 07 Mar 2012 10:27:27 +0000 Simon McVittie <smcv@debian.org> wrote: > On 07/03/12 09:34, Neil Williams wrote: > > Turn the problem around - if someone (me) comes to you about one > > of your packages with a set of changes which are necessary to be > > able to rebuild your package, say, without perl or without SSL or > > without LDAP support - how would you prefer that to be explained > > and debugged? A set of sed and awk lines for debian/rules or a > > clean set of patches to debian/ files? > > If you want me to incorporate changes, I'd prefer them as a git patch > (series) for debian/ in my packaging repository, or failing that, an > equivalent of the output of nmudiff (which is roughly equivalent to a > single git commit touching only debian/). Exactly - a patch to the existing debian/ directory is best. To incorporate the changes, the changes need to be isolated behind a DEB_BUILD_OPTIONS or dpkg-vendor. The problem comes when the conditionals themselves are not enough and the alternative build needs to apply a patch against (or otherwise modify) the files in debian/ like maintainer scripts and .install files. There are two modes involved here: ongoing maintenance in Emdebian to keep up with unstable and eventual integration into the Debian packages. So, for the first mode, experiments are based on taking the Debian source package as a starting point, putting that into our VCS to be modified for the required build changes. Modifications, wherever possible, use debhelper -N or -X options, DEB_BUILD_OPTIONS and dpkg-vendor conditionals but that does not cover 100% of the modifications required. From our VCS, eventually, we'd see if maintainers are willing to integrate such changes but there are issues there with long term maintenance because maintainers aren't that likely to test the effect of future changes on the modified build. Therefore, during development of the changes, it can become necessary to patch the debian/ directory each time the package changes in Debian. These builds aren't based on stable - these are frequently changing packages in unstable. Keeping up with Debian with a set of modifications to debian/ files is not easy. It's experimental at this stage, but what I'd like to able to achieve is to prepare the modifications based on one version, optimise, test, etc. then when the changes are complete, *migrate* those changes to whatever other changes have been made upstream. If that can be done automatically by patching debian/ all well and good, otherwise each new Debian version involves a lot of work porting the same modifications again and again. This what I hope most Debian maintainers would expect Emdebian to do. The problem comes when the conditionals are not enough and we start looking at the second mode. Now we're talking to an interested maintainer who wants to have our modified build supportable in Debian and is willing to work with us to keep the modified build current. In a lot of cases, I hope, that will just be a set of dpkg-vendor/DEB_BUILD_OPTIONS conditionals. However, experience has shown that this does not cover all cases and there remains the thorny problem of exactly how to keep the modified build working alongside the normal build when some of the maintainer scripts and/or .install files just need to be patched for the modified build to operate. (In the initial case, the helpful maintainer will be me, working on my own Debian packages for Emdebian support - just as I did with the first release of Crush.) > This is somewhat orthogonal to the format in which you distribute your > source packages, though, surely? If I obtain the .debian.tar.gz for a > modified version of my package and want to merge the changes, > debian/changelog tells me where we diverged, and to get from there to > a nice patch, I'm quite capable of operating diff on my own :-) Correct. My problem is in keeping up with your changes and trying to automate some updates for those times when 1.2.3-2 only differs from 1.2.3-1 in files which don't need to be modified for our build of 1.2.3-2em2 - we can simply apply the patch from 1.2.3-1em2 and update our package with the Debian updates. Of course, there will be plenty of times when this fails (so patch --dry-run). Whether it applies or not, some modifications look like a new patch would have to be introduced which applies against files in debian/ to fix problems which dpkg-vendor and debhelper don't appear to be able to handle. An example is my QtEmbedded build for Emdebian which can't be completely encased in dpkg-vendor/DEB_BUILD_OPTIONS conditionals and I'm at a loss to work out quite why. The debian/ directory at [0] is based on qt4-x11 from Squeeze, if anyone does want to compare and contrast. > If you don't want me to incorporate changes (for instance because > they're Emdebian-specific things which actively remove functionality), > then I don't care how you maintain them - do whatever works - but I > would suggest that branching the source package in a VCS (hint: > git-import-dscs --debsnap) is likely to be more sustainable than > patching or applying sed/awk at build time. I guess what I'm getting at is that, throughout the time we've been doing Emdebian stuff, we have come across corner cases which the "typical" methods do not support and in the process of experimenting with how to fix things properly, there are times when unconventional approaches (such as patching debian/ files during a modified build) become necessary, just to keep up. Whilst I can see the problems this would cause in typical Debian packages, I don't want to see such useful mechanisms prohibited because the tools will then have an excuse to start to prevent these methods from working. I know we shouldn't be doing these things but until we can work out why the standard tools aren't working as expected, unconventional methods can at least keep the updates happening. [0] http://www.emdebian.org/trac/browser/current/emdebian/trunk/qt4-embedded/trunk/debian -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpz3r2AWvUWq.pgp
Description: PGP signature