Re: How to handle Debian patches
Goswin von Brederlow dijo [Tue, May 20, 2008 at 08:10:05AM +0200]:
> >> If I understand things correctly (but I'm really not sure I do), 3.0
> >> (quilt) won't really help with that: it won't prevent maintainers to
> >> directly modify files outside of debian/ , and generate a huge
> >> debian/patches/debian-changes-version.diff.
>
> Yes it will. Any modified file will end up in debian/patches/ instead
> of modifying the file directly. It will not prevent patches but it
> ensures they are used exclusively. So no packages that change some
> files directly and use debian/patches/ for others.
Ok... I have not followed the development of the new package version
> > But with some time put to it, we can end up including a "the
> > maintainer shuold not modify files outside of the debian/ directory
> > without a strong rationale", and provide lintian checks for packages
> > still directly modifying upstream code...
>
> Do you mean no debian/patches at all?
No, of course not - But I _do_ mean no patches with no rationale at
all. If I understand correctly, were I to repackage something I have
now that directly modifies the upstream code, my whole unorganized
patchwork probably become something like debian/patches/01. Of course,
a tool cannot understand _what_ it does, and how it should be split. I
suppose (and, again, I'm just guessing right now, please forgive me) a
good maintainer would split and name that in
debian/patches/01_fixes_blah, debian/patches/02_foo and so on, and in
each of the files' headers would note what bug or issue is this patch
addressing. And we can make tools understand said headers - and
complain if an unexplained patch was found.
Greetings,
--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Reply to: