Hi, On Mon, 26 Jun 2017, Johannes Schauer wrote: > > 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?
It would because actually I pass "--apt-update --apt-upgrade" but not "--apt-distupgrade" and I have no ~/.sbuildrc. But then it would likely have to do something else to update the build choot. That said I don't think that changing the default is the right answer here. > > 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. When I call "sbuild" I want a package build, it should not fail if it is able to build the package. If I call sbuild-update --dist-upgrade, I might understand that you would like the command to fail. > > 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? Yes. > 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. Yes. But that's the kind of temporary dependencies problems that happen from time to time in unstable too when an architecture's buildd(s) lag(s) behind. > > > > 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 afraid we don't have the same definition of "succeed". It's normal for a dist-upgrade to keep some packages on hold when doing otherwise would remove packages that the user wants to keep. For end users, this happens all the time in unstable during large transitions. You don't want to get the latest perl until all the perl modules that you have installed have been rebuilt. For a build chroot, we want the opposite... as long as it doesn't break the build chroot. If the new perl causes the removal of dpkg-dev, then it should not be dist-upgraded. If it causes the removal of liblocale-gettext-perl only, then it's fine. > 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. Then make the --apt-distupgrade a tri-state option: never/always/when-possible and make it default to "when-possible". But to me it seems like useless complexity when 99,9% of the users just want the build to succeed with the freshest working build environment that we can get in the current situation. > 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. I don't understand the analogy. The archall-only build is really about what we want, if we can't get what we want, it should fail. The --apt-distupgrade and not about what we want, it's about the environement, it's more in the realm of the "how". And while you interpret the option literaly as "the user wants a dist-upgrade" I believe that it should be understood as "I want a package build in the latest build environement available". > 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? The problematic dependency is on libc6-dev and I don't control that one. > 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. I have plenty of ways to hack a solution but if I file a bug report, it's because I believe that it is a shortcoming that should be fixed for all, not only for my specific case. > 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? Such additional work would solve this issue it would also multiply the amount of work by ten (i.e. much more than having to deal with this specific hiccup) and it would offer no benefits for the end users. 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/
