On Thu, 17 Mar 2011, Andreas Tille wrote: > On Thu, Mar 17, 2011 at 04:09:25PM +0800, Paul Wise wrote: > > Agreed. That would usually not be something that would cause enough > > problems for a new tar.gz to be warranted though. > > I just accept your opinion that repackaging is not warranted and I did > not in the past - but I was never really sure whether this is really > reasonable. I'm somehow missing *clear* rules when to rebuild the orig > tarball and when not.
If it breaks something, it violates the DFSG, or it increases the chances of massively confusing someone or breaking a security build/NMU/binNMU, rebuild it (and *document* it properly). Otherwise, don't. It is a bit simpleminded, but it has worked for me for 15 years, so far. For a while I had "debian/rules clean" cleaning up some of the mess more likely to show up, and it was simple enough for anyone to understand how it interacted with the build at first glance... but it was certainly NOT simple for people to grasp how to regenerate the list of supposed-to-be-executable files and supposed-to-be-deleted-on-sight files. But all my upstreams got better at rolling release tarballs, and after a couple years without any need to use any such fixups, I dropped that machinery in the name of simplicity. Now that we have get-orig-source targets, such heavy-handed cleanups even have a place to live that is standard and fully documented. > > > If you try to build the source twice in a row you get a diff to the > > > original tarball. This should be avoided. > > > > I would just have `debian/rules clean` remove the (re-)generated files > > as per usual. > > I understand the requirement to build a package "twice in a row" as it > was discussed here[1] (including link to policy) that the removal of > those files is not OK. You can have packages that build properly n times in a row, for n > 0, without messing with the debian diff, even if you remove files in debian/rules clean and do full retooling on every build. Debian QA was complaining of broken packaging that did not do that, and NOT of the removal of the files themselves. Note that any non-reversible transformation of the package source during build IS against policy. I cheerfully ignore that requirement as long as the packaging is properly done (i.e. it not only rebuilds as many times in a row as you want, it ALSO always rebuilds in the same way, INCLUDING in the first time, and INCLUDING source package builds, not just binary packages). I consider that policy requirement an artifact of dark times we've long left behind. As I said, I have never been presented with an usecase that requires that policy of only allowing reversible transformations in the first place, and I didn't have enough imagination to come up with one that fit reality. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110317134838.gb1...@khazad-dum.debian.net
