Re: Please, minimize your build chroots
On Sun, Jan 29, 2023 at 05:00:56AM +0100, Guillem Jover wrote:
> On Sat, 2023-01-28 at 21:35:01 +0200, Adrian Bunk wrote:
> > I don't think such arguments are bringing us forward,
> > we should rather resolve the problem that these differ.
> >
> > All/Most(?) packages where they do differ are packages that were until
> > recently part of the essential set, and since debootstrap still installs
> > them they are in practice still part of the build essential set.
>
> Sure.
>
> > Removing tzdata from the essential set made sense, and I do see your
> > point that tzdata does not fit the "totally broken" definition of
> > "required".
>
> > What we need are technical discussions like whether packages like tzdata
> > should also be removed from the build essential set, or whether tzdata
> > being a part of the build essential set should be expressed by making
> > the build-essential package depend on tzdata.
>
> I guess my question is, what makes tzdata build essential, besides
> that it's currently kind-of implicitly there? To me it does not look
> like it has the properties to be considered as such, besides that if
> we lower its priority (as it deserves) it makes a bunch of packages
> FTBFS.
It has historically been part of the build essential set.
It is used in the build of many packages.
There would be so many invisible undeclared build dependencies of
packages using it who have it pulled in by other packages that random
changes in the dependency tree might cause many packages to FTBFS at
any time if it does not stay build essential.
It is required to provide glibc functionality that is frequently
used during the build.
> So, for one, this is getting in the way of making our minimal
> (non build) systems smaller.
No, it is not.
There are 3 different topics:
1. making minimal (non build) systems smaller
Being able to exclude tzdata from a minimal system was achieved when it
was removed from the essential set in stretch.
debootstrap not installing it by default would make that easier.
Whether build-essential depends on tzdata does not make any difference.
2. normal systems
In a normal (non-minimal) installation not having tzdata installed
would be a bug harming many users, no matter what priority it will
have.
3. build essential
That's separate from 1. and 2.
> > I have so far not seen any technical arguments why removing tzdata from
> > the build essential set would be better for Debian than keeping it there.
> > Removing tzdata reduces the size of a chroot that has the build
> > dependencies for the hello package installed by ~ 0.5%, this size
> > decrease does not strike me as a sufficient reason for reducing the
> > build essential set.
>
> I don't see how this can be a pure technical decision, TBH. To me this
> looks more like either a matter of trade-offs,
It is a tradeoff between less work and saving ~ 0.5% space in build
chroots.
> or IMO more importantly
> of clean definition of a specification (which seems rather more
> important than the other concerns). The work to spot these problems has
> already been done, and the changes required are trivial and minimal
> (disregarding any severity consideration here).
The work has been done for packages that do FTBFS today.
I would guess ~ 90% of the packages that did have tzdata installed
during Santiagos builds did not have or need a direct build dependency
because something else pulled it in.
It is unknown how many of these would have a latent FTBFS bug due to an
undeclared direct build dependency.
Do we have any packages that build successfully but are broken without
tzdata installed during the build?
>...
> I appreciate the minimalism and simplicity of the definition. I've
> also heard from time to time complains that we even require a C/C++
> compiler as build-essential, when for many packages that's not even
> needed (although a C compiler is currently needed by dpkg-dev to
> determine the host arch).
I would also complain that dpkg-dev pulls the full perl into the build
essential set.
The build essential set is so huge that I wouldn't even be surprised if
at some point in the future this discussion becomes moot because some
package in the build essential set gains a dependency on tzdata.
Perhaps some localtime related functionality could justify a dependency
of perl or perl-modules-5.36 on tzdata, which would keep it in the build
essential set due to dpkg-dev being build essential?
> Policy also has this to say:
>
> ,---
> If build-time dependencies are specified, it must be possible to build
> the package and produce working binaries on a system with only
> essential and build-essential packages installed and also those
> required to satisfy the build-time relationships (including any
> implied relationships). […]
> `---
>...
I don't think this is helpful for the discussion whether packages that
were previously part of the essential set should stay part of the build
essential set.
"Important: yes" e2fsprogs is an even bigger problem here:
It is rarely used during the build of a package and shouldn't stay part
of the build essential set for that reason, but as long as apt refuses
to remove it when it is already installed I don't think such
a nearly-essential package can be removed from the build essential
set because something like
Build-Conflicts: e2fsprogs
would then be both permitted and likely cause problems.
> Regards,
> Guillem
cu
Adrian
Reply to: