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 - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]