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

[Raphael Hertzog]

Hi,

On Sun, 25 Jun 2017, Johannes Schauer wrote:
> > 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.

Then it would make sense to not have APT_DISTUPGRADE=1 by default. Having sbuild
refusing to build in that situation is not really helpful either.

To me it seems perfectly fine to just emit a warning saying that the
distupgrade has not been made because it would have broken the chroot.

> > 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?

Huh... not really, I think you misunderstood, cf below.

> > 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?

I'm not building src:glibc, I'm importing it from Debian in kali-dev and
the run I run britney to create kali-rolling to ensure that broken
dependencies are detected and are not part of kali-rolling.

> 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?

My fork of linux has a higher version number than in Debian, except that
updating the fork takes a bit of time and when glibc and the kernel
migrate together in testing (that's what we track) I get the updated glibc
immediately (because it's not forked) and we update our out-of-sync
package like once a week (or sooner when we see it creates migrations
problems).

> > 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.

Indeed. I don't see why a warning would not be sufficient. Or doing it in
two steps "apt-get install build-essential, apt-mark hold build-essential,
apt-get dist-upgrade"

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/