Bug#517650: lintian: changes made to collection scripts are not reflected unless a package changes
Raphael Geissert <atomo64@gmail.com> writes:
> When a collection script is modified, the changes are not reflected even
> if the same package is re-unpacked or re-processed. This could lead to
> certain temporary miss behaviours.
That's why you're supposed to increase the lab format version when you
change collect scripts. There is already a mechanism in place to handle
this; we're just bad about using it. However, that's a single version
number for the whole lab, whereas your proposal is finer-grained and, I
think, better.
> IMHO the most reasonable way to make sure the data generated by the
> collection scripts is rebuilt when the collection script is changed, is
> by using per-package status files. With this, the Output information on
> the .desc files would be obsolete and replaced with another field that
> could be named 'Version'.
>
> The complete proposal is:
> * Drop Ouput fields.
> * Add Version fields, with an integer value, to each and every .desc for each
> and every collection script.
> * The frontend would, whenever a collection script is run, attempt to remove
> any .$collection_script* file (e.g. .file-info*) from the package directory
> and when the script finishes, touch the .$collection_script$version file.
> * Skip a collection script if the .$collection_script$version file exists.
>
> If it is fine I'll implement it.
The one tweak that I'd make is to list all of the files that a given
collection script creates in the Output field still, but use that only to
determine which files to remove when the version is out of date. That
way, we don't have to change the naming of the existing files when they
don't match the collection script name, and most of the work of listing
the output files is already there.
BTW, I'm increasingly coming around to your idea of eliminting the unpack
scripts and just making them all collection scripts. It would simplify
things a lot, and it would let this system handle out-of-date unpack
scripts as well. (Hacking on unpack-srcpkg-l1 was rather annoying.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: