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

[Johannes Schauer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170626/97a435c7/attachment.sig>