Hi, Quoting Raphael Hertzog (2017-06-25 22:32:41) > > > 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.
Just to make sure I understand you: changing the default would probably not fix your situation 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. Maybe to you it does but I do not want a tool that I told to do X to go on and do it stuff even though it failed at doing X. If I tell a tool to do X and it is unable to, then it should fail. > > 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. I assume kali-dev and kali-rolling are suite names? > > 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). Ah, but because the glibc you imported was not built with your kernel the binary packages that end up in your repos have the "wrong" versioned dependencies. > > > 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" But if you put a hold on build-essential, then the distupgrade will not be able to install the packages it needs to succeed. I'm still not sure what sbuild is supposed to do here to solve this problem. Having "apt-get distupgrade" either silently (with just a warning but without killing sbuild) fail or not do the full upgrade seems wrong to me because if the user requested a distupgrade and cannot get one, then sbuild should abort. Otherwise that would be like the user requesting to do a archall-only build but if it cannot sbuild will just issue a warning instead of failing. Implementing a check whether build-essential is to be or was removed sounds useful but it will not solve your problem. Another option would be to add a command line option --allow-unsuccessful-distupgrade which would not distupgrade if it breaks the chroot. But sbuild already has so many command line options and special exceptions that I'm hesitant to add another one. Or maybe, since you already forked src:linux, maybe it would be possible to let the linux-libc-dev package be built with the version number from testing? If you are really set on letting sbuild silently fail if "apt-get upgrade" fails you could instruct your buildds to not do the distupgrade by default but you do it manually using --chroot-setup-commands. Using that you can then handle the situation however you like. And does the problem not ultimately come from how kali imports packages from testing? Should you not rebuild all reverse dependencies of packages that you fork to make sure that the source packages you offer have been built against the right binary packages? So would the problem not also be solved if you would also rebuild src:glibc? cheers, josch
signature.asc
Description: signature