Re: Best practice for cleaning autotools-generated files?
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
Reply to: