Dear Holger,
lördag den 8 oktober 2011 klockan 10:39 skrev Holger Levsen detta:
Hi Mats,
On Freitag, 7. Oktober 2011, Mats Erik Andersson wrote:
Would it be possible, and suitable, to have Piuparts implement
an examination of the compression type used on a package?
I'm not sure it would be suitable.. as one could see in the bugs you
mentioned, those bugs are detected manually very fast, as they completly
break
d-i/debootstrap.
Yes, but they did so because the three packages were built
in way that would predictably break the bootstraping stage.
libacl1 and libattr1 were blockers for thirteen days,
the time span for libgssglue1 cannot be determined
from its changelog alone. Personally, I would have wanted
an automatic detection that sent a warning to the
maintainer almost immediately after the upload into
the unstable pool.
While on the other hand...
To prevent bugs like those mentioned, one would need to
identify which compression types the bootstrapper supports
in the installer at all times
how would you do that?
A human statement regarding compression capabilities found in
the debian-installer and possibly a verification that the
packages brought in by deboostrap-base did not add some
further decompression facilities. An automatic detection
is probably beyond reach.
, and one would need to keep
track of which dependencies are brought in by the installer.
how would you do that? (I think thats easier than the former, but still...)
Examine the dependency tree present in the debootstrap-base.
This is the installer step that broke in both the cited bugs.
This latter information should be readily available already,
or at least traceable, and the first piece of information
is even simpler to register.
probably. but then it's also easy to setup a daily cronjob which runs
debootstrap :-)
Also/but I think the correct solution is to setup automated d-i installation
tests, (and not to add more functionality to piuparts which is basically
outside of piuparts scope).
The resolution of this bzcat bug family was delayed by the weak error
message produced by debootstrap. (I will file a wishlist bug on this.)
Thus an automated installation test would only tell that something
was broken, but it would not have given pointers to the three library
packages. Only curiosity and some inspired manual inspection brought
the culprits to daylight.
There is a lot more which can go wrong in d-i (ie breakage of common tasks),
and IMHO there should be automatic tests to detect those.
So I'm very tempted to close this bug as wontfix. Comments from other people
reading this?
You are most probably correct in both these respects. But the ball
might now be rolling.
Regards,
Mats E A
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
