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

[Raphael Hertzog]

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/