[buildd-tools-devel] Bug#865541: Bug#865541: sbuild --apt-distupgrade should not remove build-essential

[Johannes Schauer]

Hi Raphaël,

Quoting Raphael Hertzog (2017-06-23 15:17:50)
> No, I just want the integrated "dist-upgrade" feature to not break the
> build chroot. My definition of "breaking the build chroot" includes
> "removing build-essential".

right, that makes sense. Sbuild should never remove the build-essential package
from the chroot.

It should at least error out when it accidentally does remove it.

> It happens that the repository that I was using had a broken libc6-dev (until
> I updated linux-libc-dev to a newer version) but since libc6-dev was already
> installed in the build chroot, sbuild should be able to build the package
> anyway and just be happy to keep libc6 on hold instead of force-upgrading it
> by removing build-essential.

Yes, but by having the APT_DISTUPGRADE configuration option set to 1 (the
default), the user instructed sbuild to do a "apt-get distupgrade" before the
build. Imagine a user who not just implicitly (through the default) but
explicitly (for example via the ~/.sbuildrc) instructed sbuild to do a
distupgrade but then sbuild doesn't do that and some packages don't get
upgraded. I think as a user explicitly requiring a distupgrade I would expect
sbuild to fail if it cannot perform a distupgrade in a way that doesn't remove
an important package like build-essential. So I don't think it would be a good
solution to add code which by default does only part of a distupgrade.

> This works only if you are able to anticipate the problem. Once libc6-dev has
> been removed from the build chroot, you can't reinstall it as the version
> available in the repository is broken. So you are stuck and must somehow
> manually downgrade to another working version.
> 
> Note also that we are speaking of build daemons where our usual
> interaction is just to upload a package... temporarily modifying the
> sbuild configuration of the build daemon is painful.

Your problem sounds like a bootstrapping problem. You have a build-dependency
cycle between two source packages where each package needs each other to be
built. Thus, would a stage1 package built using build profiles not be able to
solve your situation?

Also, coming back to your first email (which I think I now understand better)

> This happens from time to time in Kali because we have forked linux (which
> builds linux-libc-dev) but not glibc (which builds libc6-dev).  libc6-dev
> embeds a >= dependency on linux-libc-dev on the version on which it was built
> against and is thus non-installable in Kali until we have updated the
> kernel...

So you are building src:glibc using a non-kali kernel?

Why is a >= dependency a problem? Isn't your fork of src:linux not having a
higher version number than the version it comes from?

> > Could you expand on your issue so that I can understand what exactly it is
> > that sbuild is either doing wrong or what you would like sbuild to be able
> > to do?
> 
> I would "sbuild-update -d" to ensure that it doesn't remove
> build-essential (assuming that's what sbuild calls when we use
> --apt-distupgrade).

Assuring to not remove build-essential is a good idea but it wouldn't solve
your problem if I would just ensure this by throwing an error if apt removes
build-essential because it wants to dist-upgrade.

I'm hesitant to add a --dont-distupgrade-if-removes-buildessential switch to
the command line options until I'm sure that there is no better way.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170625/26b358d8/attachment.sig>