[Pkg-libvirt-maintainers] Bug#825423: [buildd-tools-devel] Bug#825423: supermin + sbuild + linux-image = broken chroot

[Santiago Vila]

severity 825423 important
thanks

On Thu, May 26, 2016 at 10:34:12PM +0200, Johannes Schauer wrote:

> this seems to suggest that you are not using a throw-away chroot but
> a persistent one. Could you provide details about your chroot setup?
> Are you not using schroot?

I am using schroot. This is my /etc/schroot/chroot.d/stretch file:

[stretch]
type=directory
description=Debian stretch
directory=/chroot/stretch
groups=sbuild
root-groups=sbuild
preserve-environment=true

> That linux-image-4.5.0-2-amd64 cannot be uninstalled is not a bug in sbuild but
> a bug elsewhere. That a package cannot be uninstalled is nothing sbuild can do
> something about.

Well, except if, by mutual agreement, some mechanism is agreed between
maintainers to ensure that a package may be uninstalled.

> If anything, it is the responsibility of the chroot management
> system to provide workarounds for situations like this if that's the last
> ressort.
> 
> > The reason for this, I think, is that linux-image refuses to be uninstalled
> > if it detects that it's the same version which is running in the system.
> > 
> > 
> > This check, however, fails to account this case, where the linux-image
> > being removed is the same version but not actually the same which is running,
> 
> if that is the case, then this sounds like a bug in the source package linux.

Yes, this is what I think. If you feel uncomfortable with the fact
that I submitted this report against three different packages, feel free
to make a reassign. I just wanted to hear the input from the maintainers
of the affected packages.

> > I think it should not be too much difficult to check that we are not in a
> > chroot.
> > 
> > If we are in a chroot, removing the package should succeed, even if the version
> > matches the linux-image running in the ssystem.
> > 
> > 
> > Alternatively (and this is where the bug would not be only a bug in linux),
> > linux-image could provide some kind of escape mechanism allowing sbuild
> > to uninstall it successfully.
> 
> I do not think it's a good idea for anybody to mingle with the dpkg database or
> maintainer scripts except for dpkg or the package itself.

Neither do I. By "escape mechanism" I meant something like sbuild or
schroot creating a file which linux-image can then check for existence.

I believe such file already exist (/etc/debian_chroot), that's why I think
this problem should be easy to solve.

> [...]
> 
> sbuild is indeed used on the buildds but those are using trow-away chroots
> where it will not matter whether packages fail to uninstall. Since your setup
> is different, I don't think buildds will be affected by this problem.

Well, I'm downgrading to "important" just in case it helps the discussion.

I've seen too many people angry for FTBFS bugs just because they don't
happen in the official autobuilders right now, but I think our standards
should be higher anyway (in the sense that packages must build from
source noy only in the official autobuilder, not only when LANG=C,
not only when the filesystem is ext4, etc.)

Thanks.