[Piuparts-devel] Bug#644626: Bug#644626: piuparts: Testing package data compression

[Mats Erik Andersson]

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