Bug#517650: lintian: changes made to collection scripts are not reflected unless a package changes
Russ Allbery wrote:
> Raphael Geissert 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.
I though the lab version number was only being bumped on changes to the
unpack scripts or other structure-related changes.
>
>> 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.
I didn't consider that because most (if not all) of the collection scripts
either open files for writting (and not appending) or remove them before
writting/appending anything to them.
> 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.
I'm not quiet sure what you are concerned about, could you please elaborate?
but while trying to figure out what you meant I noticed that if a
collection script used to generate a given 'foo' file but in a later
version the file name changes the old file won't be removed. The only
easy-to-do possible way to remove it would be to make the collection script
to remove the old file if it exists. But I'm not sure we should care much
about those corner-cases.
>
> 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.)
>
Good :) but in order to properly do it I would like to drop the Order entry
from the collection/*.desc files and implement a simple dependencies
resolver. That would allow a chain-reaction-like execution of collection
scripts.
I've also though about running the check scripts as soon as their Needs-Info
collection scripts are done, while the other collection scripts keep
running; but I think I'm dreaming too much. I mean, it is not impossible,
but would need quite some changes to be made on the frontend.
Talking of which, I think it needs a cleanup and some of its code moved to
modules; it is not easy to read and hack.
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
Reply to: