On to, 2008-01-31 at 09:19 +0100, sean finney wrote: > is there any reason why this issue couldn't be solved by amending policy (or > just simply patching dpkg-source) to require that "debian/rules patch" (or > some less commonly used name if we're worried about existing implementations > of this rule) is called as part of the unpacking process or a source package? > > just a thought...
That would be one possible way of implementing it. I'd be satisfied with that, and it's in the spirit of the way Debian tries to standardize on interfaces that don't unduly limit implementation. To prevent having to add a no-op to thousands of source packages that don't use a patch management system, a tweak to the rule might be appropropriate: the target is only required if the debian/patches directory exists. Alternatively, only if debian/control's source package stanza has a "Patch-System: simple-patchsys/quilt/dbs/..." header. On the other hand, this would require at least some of the build dependencies be present at the time of unpacking the source, unless we make quilt and cdbs and dpatch etc build essential. Perhaps it would be better to make the creation of the source package create a .diff.gz that already has the patches applied? This may be more complicated to change, and probably requires changes to how the patch systems are used. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
