[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Quilt patch for patching things in the debian folder

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.



Neil Williams

Attachment: pgpl9jaNBn_Hp.pgp
Description: PGP signature

Reply to: