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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]