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/
