Bug#513663: [general] need infrastructure to check related packages
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2011-01-06 20:18, Russ Allbery wrote:
> Niels Thykier <niels@thykier.net> writes:
>
>> Speaking of unpacking; as I understand it we once had an "unpack-level
>> 2" which has now been removed in favour of collection. I am considering
>> to remove the "unpack-level 1" as well and move everything to collection
>> as a part of this.
>
>> I feel the unpack code makes the lintian code harder to read and
>> understand. If we migrate the last of the unpack stuff to collection I
>> think we can reduce the complexity of the "PACKAGE: foreach" loop
>> considerably.
>
> 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).
Unless I am mistaken the old unpack layer only exists to run
unpack/unpack-<type>-l1 and remove the entry on a remove action.
Starting with the latter $action eq 'remove' can easily replace the
$unpack_level variable here.
At least the bin and the changes appears to be "easy" to convert to
collection. I have not had a full look at the source script, but I
doubt it will be really hard.
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.
>> I.e. It took me a while to figure out that the $unpack_level is either
>> 1 (if $action is "check" or "unpack") or 0 if $action is "remove" in the
>> "PACKAGE: foreach". No other $action reaches that far and the user
>> cannot influence $unpack_level (beyond changing $action).
>
> Yeah, there's a lot of code that does stuff like that in frontend/lintian
> that will benefit greatly from refactoring into clearer-defined modules.
>
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).
~Niels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJNJkb0AAoJEAVLu599gGRCK2EQAJRLMrWyZqIw/hpENbNIxj/W
sVPXnXYloBcrw/eKhTHOX2Kj1S848d9pvEgBnyCLGiUhLzOAjYzuI9bXmkqrINFJ
EKMy1xcpyQQ2UNtRSBTg76cYG8n39xGQ6hU9MdWedX6lHm6qGy1r7ok/3iVVUvpP
bzAn+AuDbAMGBCGmKuWKFCMjstBUpS/k8CGdYJ9AZgRxcbVbCpknZ742MRRBfwsk
uFgkueLqfTxt/HJtrJNHXmwrt70BuqZw6fxIzczrvlSShPvn8gHcrDMs+WE8G8TQ
ZphJlJPMoUTgZ0jKh/FJcTi4BnSjpiGu1VUisWxo85Vs93e+goXXbUJvaw2CqIIS
Gp2lp3xD1Oc2uNgvXceU5NHONovZT2QsP+zo2rsfI3NkS22ZFC494NKTTKuiMCLz
lHulpq7ARqVwNmCmlLwfeT+rroU+JqLl+yO1NYk2trb8OLV+2Prna6/WkkvnIHhc
PAVo7PlIvpqBRDBJq04eB8BxQ2JFQBLKf0+0Caifs7SX/5c/+Fo4mpxWjehhPzQY
YCMEporaEk4gEjmaUwQhAQaW6MMoxpOHKsTkC74Pxm7tUeAbbVMwzk4nqcyAywck
GSOYIdSIrAQkIESLmDbDRuZYjx/L4MneE1a2H2pnq7Gjlb33E1+xFRuHohscmScS
XCADG5jyjTEzNMlL3mpa
=ESFb
-----END PGP SIGNATURE-----
Reply to: