[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#513663: [general] need infrastructure to check related packages



Niels Thykier <niels@thykier.net> writes:
> On 2011-01-06 20:18, Russ Allbery wrote:

>> As long as we have some way of marking some collections as transient
>> and some collections to be retained, and then provide some way of
>> overriding that, that sounds fine.  I much prefer talking about
>> everything as collections.  We just need to retain the capability of
>> generating a Lintian lab for the whole archive without including in the
>> lab all the unpacked binary and source packages.

> Currently the "repack" is never triggered as far as I can tell.  The
> reason why lintian properly cleans up is that collections like unpacked
> contains the "Auto-removed: yes" line.  This particular line is
> currently overruled by the --keep-lab switch (or if the package lab
> disappears, but that only happens on a remove action).

Oh, right, I forgot Raphael had already taken care of that.  Okay, that's
all set, then.

> There is the one unhandled case - namely if all collection scripts
> contains "auto-remove: yes", then the directory itself will not be
> removed... but then again we do not currently handle that anyway so it
> will not be a regression.

Yeah, and I don't think we'd ever do that anyway.

> My current effort in the infra-513663 branch has been to encapsulate
> packages inside the lab and reduce the complexity of the "PACKAGE: foreach".
>   I intend to let these Lab::Package instances take care of the
> book-keeping inside its defined little space; my next goal is probably
> to make collection book-keeping go in there as well (that is creation
> and removal of the ".<script>-<version>" files).
>   I think once that is done the "PACKAGE: foreach" will be much simpler
> (at least a lot shorter).

Excellent!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: