-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-01-06 20:18, Russ Allbery wrote: > Niels Thykier <[email protected]> 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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
