Goswin von Brederlow <goswin-...@web.de> writes: >>> If you need to change a file then that means that file isn't source >>> anymore but generated. Try switching to out-of-tree builds if you have >>> something like that. >> >> What is the advantage of that? From the Debian policy, I don't see a >> need why sources should kept untouched during the build process. > > Less surprises by someone unfamiliar with the source. For example: > > - you (as in some porter, not the maintainer) build the source to > reproduce a FTBS > - it fails as expected > - you edit the broken file > - you build again and it works > - you call clean so you can make a patch > - clean restores the original source file destroying hours of your > work
If I would be unfamilar with the source, I would just not expect that the package behaves as I would do it myself. Instead, I would be ready for the case that it does tricky, undocumented things with the source -- and create the debian patch before I am going to build the package. Why should a porter expect more from a package than the requirements specified in the policy? >> It is just the better design: the package was built with a patched >> source, so only the patched version knows for sure how to clean it up. > Note that it only calls clean with unpatched sources if you > specifically unpatched your source before calling it. If you insist so much on this standard: why does debuild (or dpkg-buildpackage) undo the patches if they were not applied before? In this case, it would be up to the (rare) people to unpatch if they need this. One could even provide a debuild/dpkg-buildpackage option for that (like --unpatch-after-build or so), or do it in a hook. > So I think having the clean target make sure patches are applied if > needed is the better design. .... which again does not behave as expected: if "clean" depends on "patch", then after "debuild clean" the packages is in the "patched" state even if it was unpatched before. I think the best way would be that debuild/dpkg-buildpackage would not automatically unapply the patches (so it would leave the source in the way that is described as "standard" for Debian), with a special option or hook that does this for those who really need it (and know what they are doing). > I was describing the case of having changes commited to the RCS and > generating debian/patches/* automatically (or a single debian-changes > patch). A single debian-changes patch is evil -- even Lintian complains there. Handling a single debian-changes patch is something I would explicitely *not* take as a valid use case. Is there a way to automatically handle a bunch of individual patches trough an RCS? Best regards Ole -- 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/ytzzk926l53....@news.ole.ath.cx