Re: New optional debian/rules targets for consistency of patch systems?
On Sun, Sep 02, 2007 at 04:27:27AM -0400, Daniel Schepler wrote:
> I'd like to get an opinion on a proposal for several new debian/rules targets
> I've been thinking of for a while now. The motivation here is that the
> different patch systems have differing targets required for applying or
> unapplying patches, which is highly annoying when trying to debug packages
> using them. For example, I think dpatch uses patch/unpatch, cdbs uses
> apply-patches/unapply-patches, and dbs needs
> make -f /usr/share/dbs/something.mk debian/stampdir/patch or something
> strange like that. So for consistency, I'd like to propose the optional
> targets:
>
> unpack
> Unpacks any embedded source tarballs into a build directory, without
> applying any patches.
>
> patch
> Applies all patches to the build directory, after unpacking sources if
> required.
>
> unpatch
> Reverts all patches which have been applied to the build directory.
This would be fantastic and make working with the array of subtly
different patch systems much less painful. Rather than simply saying
"optional" for 'patch' and 'unpatch', I'd go a step further and propose
something like "source packages that apply patches after 'dpkg-source
-x' should provide the following targets".
Obviously finishing off the integration of patch systems into dpkg-dev
would be better, but this would make life a lot less painful in the
meantime.
I imagine you will be called upon to provide justification for this
particular choice of target names, at least from maintainers and users
of patch systems that currently use different ones. I would suggest the
rationale for these names that they are simple verbs in use by at least
one patch system already, and they are the shortest of the target names
currently in use.
Perhaps start by filing bugs on patch system packages to provide these
names as aliases and see if we can get some kind of vague consensus
rather than bikeshedding?
> And while I'm at it:
>
> configure
> Prepares the build directory for compilation, for example by running
> autoconf scripts.
How would this interact with source packages that perform multiple build
passes?
--
Colin Watson [cjwatson@debian.org]
Reply to: