Raphael Geissert <atom...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
