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
signature.asc
Description: signature
