On 03/07/2012 05:34 PM, Neil Williams wrote: > Not within Debian uploads and buildd's, true, but there are good reasons > for this to remain technically possible for derivatives. The ability for > someone downstream of Debian to patch debian/control[.in]
Our policy doesn't apply to derivatives (they can respect it if they want, but they don't have to). As for debian/control, I would prefer to use substitution variables, and I would avoid to use a debian/control.in (unless maybe, if you need to remove a binary from the build process entirely, or such more radical changes to the packaging, but I never met such case). On 03/07/2012 05:34 PM, Neil Williams wrote: > but there > are problems when a rebuild wants to / has to remove certain files from > the packaging. Well, that's where I believe that a debian/foo.in is a good way! On 03/07/2012 05:34 PM, Neil Williams wrote: > There are other ways of doing this but as it will remain necessary for > someone to modify files in debian/ for a customised / embedded rebuild > of any package in Debian, is it preferable to require this to be done > using sed and awk or to allow a clean patch-based mechanism which is a > lot easier for the relevant Debian maintainers to understand? > Patching things in debian/* depending on some conditions is a lot different than what I was talking about, which was some quilt patches in debian/patches that were unconditionally applied. So, let me rephrase: Should the *unconditional* patching of things in debian/* by a quilt patch in debian/patches be explicitly forbidden by the policy? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f577b72.1040...@debian.org
