I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).
I can think of two solutions for this:
A) Either debootstrap, when using buildd profile, installs only
essential and build-essential packages.
or
B) debootstrap keeps installing all required packages in the buildd profile, no matter if they are really build-essential or not, but those who
are not build-essential should have their priority downgraded to "important" by ftpmaster.
This problem was already reported here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060
and apparently we have not decided yet if we are going to do A or B,
or maybe some other thing. I don't really care how it's fixed, but I
believe it's about time that we sync practice with policy, because
currently we are doing this in a quite suboptimal way.
In the meantime: If you want to help QA and have any kind of chroot used
for any kind of QA (say, ci.debian.org or reproducible-builds, or even
your personal chroots), please try to minimize the packages there,
do not merely accept debootstrap default behaviour.
I think truly fixing this problem is a bit more tricky because most build tools
like the sbuild schroot backend require apt being installed in the chroot. As of today, the sbuild schroot backend is unable to function with a chroot that doesn't contain apt. I don't think it's conceptually possible to fix the schroot backend to work with chroots without apt because schroot (for good reason) doesn't give you root anywhere but inside the chroot.
or apt.
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
Such installations can only be found as artifacts since there does not
seem to be a supported way to upgrade them or (un)install packages
(quoting policy: "Removing a "required" package may cause your system to become totally broken and you may not even be able to use "dpkg" to put things back, so only do so if you know what you are doing.") Essentialy policy is telling us it might work to install b-d, and uninstall
Prioriry required, however dpkg might break halfway through and it would
not be a bug.
Greetings.[...]
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).
This is of course not fun for the maintainers, but it's also not fun
for people doing QA, because those bugs could be caught earlier in the
chain, but they are not. This is extra work for everybody.
(Similar bugs are even sliding into stable releases, I plan to report
a few of them against bullseye after 11.6 this Saturday, as bullseye
is the currently supported stable release).
Because people accept the default by debootrap "as is", chroots used
to build packages include packages which are neither essential nor build-essential, like tzdata, mount or e2fsprogs.
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
Then there is "e2fsprogs", which apt seems to treat as if it were
an essential package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587
This sort-of breaks sbuild when using an ordinary chroot (not overlayfs), because after building a package needing e2fsprogs, it may not be removed
and it's kept in the chroot.
I think apt authors did not think that apt is used by sbuild to
build packages. Here we would need some interface like SUDO_FORCE_REMOVE=yes, or maybe just stop doing anything at all with the Important:yes flag.
On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
Then there is "e2fsprogs", which apt seems to treat as if it were
an essential package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587
As Julian explained, it is considered "essential" because the maintainer
said so. If you don't think e2fsprogs should be considered "essential"
for a system it is installed on please talk to the maintainer.
Sure, the package is not (anymore) really "Essential:yes", but 'apt'
isn't either and will print the same message anyhow. I don't think it
would be a net-benefit for a user to invent words for different types of essentialness in apt because in the end you either know what you are
doing while removing a somewhat essential package and continue or you don't know what you are doing and (hopefully) get the hell out.
This sort-of breaks sbuild when using an ordinary chroot (not overlayfs), because after building a package needing e2fsprogs, it may not be removed and it's kept in the chroot.
"It may". Well, certainly apt won't autoremove it. Like a lot of other packages it wont even through they aren't essential or protected or whatever… ("just" prio:required is enough for example). They are not not irremovable through. It might just be a little harder to remove them
than to install them. Heck, some people believe its far easier to start
vim than to exit it.
build packages. Here we would need some interface like SUDO_FORCE_REMOVE=yes, or maybe just stop doing anything at all with the Important:yes flag.
Ironically, one of the selling points for Protected:yes (that is how the field ended up named which dpkg is supporting by now) was that it allows
to shrink the essential set (e2fsprogs even being an example) as there
is a non-empty set of people who believe users do incredibly dumb things
if you give them the option to.
I mean, we got practically bullied into replacing the "Do as I say!"
prompt with a semi-hidden cmndline flag (--allow-remove-essential)
because some wannabe YT star yolo'ed the prompt ending in misery and
somehow that was framed as our fault by everyone as we didn't show the appropriate meme-gif (rendered with caca) to make them understand
without reading [sorry, not sorry. I am not even exaggerating that much].
Due to that, you are now presented with:
| E: Removing essential system-critical packages is not permitted. This might break the system.
See? "essential" again and even "system-critical" at that.
It is all a lie of course. Nobody really needs an init system, much less
some silly metapackage for it, as long as there is /bin/sh and a keyboard.
I should make a video about it to – essentially – become famous & rich…
Btw, apt also has behaviour specifically for sbuild: 'apt-cache show mail-transport-agent' has a zero exitcode even through that makes no
sense at all apart from not making (some?) sbuild versions explode.
You are welcome. I hate it.
Quoting David Kalnischkies (2022-12-18 17:18:28)
On Fri, Dec 16, 2022 at 03:38:17PM +0100, Santiago Vila wrote:
Then there is "e2fsprogs", which apt seems to treat as if it were
an essential package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826587
As Julian explained, it is considered "essential" because the maintainer said so. If you don't think e2fsprogs should be considered "essential"
for a system it is installed on please talk to the maintainer.
Sure, the package is not (anymore) really "Essential:yes", but 'apt'
isn't either and will print the same message anyhow. I don't think it
would be a net-benefit for a user to invent words for different types of essentialness in apt because in the end you either know what you are
doing while removing a somewhat essential package and continue or you don't know what you are doing and (hopefully) get the hell out.
would it be so difficult to cater to both kind of users? For those who do not know the terminology, using the word "essential" is probably fine. But for those who do it's confusing. Why can apt not say something like:
WARNING: The following packages will be removed. Apt considers them essential because they are marked as Priority:required. This should NOT be done unless you know exactly what you are doing!
"It may". Well, certainly apt won't autoremove it. Like a lot of other packages it wont even through they aren't essential or protected or whatever… ("just" prio:required is enough for example). They are not not
Due to that, you are now presented with:
| E: Removing essential system-critical packages is not permitted. This might break the system.
See? "essential" again and even "system-critical" at that.
It is all a lie of course. Nobody really needs an init system, much less some silly metapackage for it, as long as there is /bin/sh and a keyboard. I should make a video about it to – essentially – become famous & rich…
Dammit, and now you wrote that one can use in a public forum that it's possible
to add --allow-remove-essential! Think of the children!
Btw, apt also has behaviour specifically for sbuild: 'apt-cache show mail-transport-agent' has a zero exitcode even through that makes no
sense at all apart from not making (some?) sbuild versions explode.
You are welcome. I hate it.
Errrr... lets change that. What's the problem in sbuild?
El 27/1/23 a las 22:37, Adrian Bunk escribi:[...]
This is not the right time to change policy.
In general, disputing the severity because it does not happen in the buildds misses completely the point of what should be the goal, namely, a distribution
which may be rebuilt by everybody following documented procedures, not
a distribution which may only be rebuilt in our buildds.
The end user MUST be able to rebuild the packages. Otherwise our
free software licenses are meaningless in practice.
[...]It is not helpful if people try to force the few people who are doing
QA work to spend their scarce QA time on fixing bugs that only happen
when building on single-core machines or in non-UTF-8 locales or without packages that are in practice installed everywhere, by making such
issues that are not a problem on our buildds release critical bugs.
That's the wrong approach. If the end user wants to make a modification,
they can't use our buildd network.
Policy is not a religion. Policy has many bugs. Policy is very outdated. >[...]Your argument cuts both ways. Right now, Policy says that
Here's an example you could follow: >https://lists.debian.org/debian-policy/2022/12/msg00023.html
Policy is not a religion. Policy has many bugs. Policy is very outdated.
Claiming there's no point to free software when the problem is simply
that you are using an *unsupported* setup?!?!
All debootstrap variants
include Priority: required packages. As you can see they do so for a
reason!
The --exclude option of debootstrap works equally well even on
Essential: yes packages.
If you think people should be able to build on top of their regular
install with various packages installed and various configurations it
If you think every packages should list just about all of the archive in Build-Conflicts just to not pick up unwanted extra autodetected
dependencies that make the package FTBFS then I think it would be
Hi Andreas,
* Andreas Henriksson <andreas@fatal.se> [2023-01-28 12:50]:
Policy is not a religion. Policy has many bugs. Policy is very outdated. >[...]Your argument cuts both ways. Right now, Policy says that
Here's an example you could follow: >https://lists.debian.org/debian-policy/2022/12/msg00023.html
the bugs are RC, and if you believe that should be different, why don't you propose such a change and seek consensus yourself?
To me it seems that we nearly are already at (2). The debootstrap bug #837060 has a working patch and mmdebstrap exists that can do what is needed today. Santiago did an archive rebuild to make sure our source package compile in a chroot without Priority:required.
Why do people call just accepting that Priority:required packages have to be part of the buildd chroot the easier solution? We just need to fix debootstrap
bug #837060 and we are done, no?
I think the much more interesting question is in what environment we want to build our packages in. Currently, on buildds, we build them in a chroot that has Priority:required and build-essential because of (what I think is) a bug in
debootstrap: #837060
So there are two ways forward:
1. accept that Priority:required is needed for building source packages
- adapt Debian policy accordingly
- revert the changes to packages made due to Santiago's bugs
- change all tools that do build dependency resolution to now also
consider Priority:required packages
2. make sure that packages are built without Priority:required packages
To me it seems that we nearly are already at (2).
could we decouple the policy and bug severity question from the question of what a buildd chroot should contain, please?[...]
Why do people call just accepting that Priority:required packages have to be part of the buildd chroot the easier solution? [...]
...
Why do people call just accepting that Priority:required packages have to be part of the buildd chroot the easier solution? We just need to fix debootstrap
bug #837060 and we are done, no?
Thanks!
cheers, josch
On Sat, Jan 28, 2023 at 02:28:30PM +0100, Johannes Schauer Marin Rodrigues wrote:
could we decouple the policy and bug severity question from the question of what a buildd chroot should contain, please?[...]
Why do people call just accepting that Priority:required packages have to be
part of the buildd chroot the easier solution? [...]
because people get upset if they receive bug reports with severity serious when they don't perceive these bugs as serious.
happened more than 9000 times already.
Johannes Schauer Marin Rodrigues writes:
I think the much more interesting question is in what environment we want to
build our packages in. Currently, on buildds, we build them in a chroot that
has Priority:required and build-essential because of (what I think is) a bug in
debootstrap: #837060
I would rather say: The build-essential packages are those installed by debootstrap's buildd profile. At least that seems to be current practice
for a long time.
So there are two ways forward:
1. accept that Priority:required is needed for building source packages
- adapt Debian policy accordingly
AFAIU it would not need changes? Policy doesn't seem to explicitly state
what packages are actually build-essential...
- revert the changes to packages made due to Santiago's bugs - change
all tools that do build dependency resolution to now also consider
Priority:required packages
Why would they need changes? Do they explicitly include essential
packages too?
2. make sure that packages are built without Priority:required packages
To me it seems that we nearly are already at (2).
I think we are already at (1) given everything works already?
El 28/1/23 a las 12:50, Andreas Henriksson escribió:
Claiming there's no point to free software when the problem is simply
that you are using an *unsupported* setup?!?!
Unsupported by whom? What is supported or unsupported is explained in policy. Policy says it must work. Therefore it should be supported (by fixing the bugs).
That's a straw man. I'm not proposing anything of the sort. Policy says packages must build when essential and build-essential packages
are installed (plus build-dependencies).
You and others are essentially saying I should not follow policy
Do you agree that the software in our archive should agree on which
packages are needed to build a source package? Currently, they do
not. dose3 requires only Essential:yes and build-essential being
installed. Who is buggy?
And I asked in my mail to please "decouple the policy and bug severity question
from the question of what a buildd chroot should contain" for a reason.
Discussing policy questions and bug severity distracts from the actual question
that I find interesting.
...
My proposal is to fix debootstrap #837060 (patch is in the bug report) so that
it only installs Essential:yes, build-essential and apt and discuss if it makes
sense to have packages like tzdata or e2fsprogs in a buildd chroot or not and if yes, add those packages as dependencies of the build-essential package.
...
Thanks!
cheers, josch
On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote:
Unsupported by whom? What is supported or unsupported is explained in policy.
Policy says it must work. Therefore it should be supported (by fixing the bugs).
Policy §2.5:
# "required"
# Packages which are necessary for the proper functioning of the
# system (usually, this means that dpkg functionality depends on
# these packages). Removing a "required" package may cause your
# system to become totally broken and you may not even be able to use
# "dpkg" to put things back, so only do so if you know what you are
# doing.
That's a straw man. I'm not proposing anything of the sort. Policy says packages must build when essential and build-essential packages
are installed (plus build-dependencies).
Build-essential _packages_. Not the "build-essential" package which very clearly says its dependencies are purely informational.
On Sat, 2023-01-28 at 16:32:17 +0100, Adam Borowski wrote:
On Sat, Jan 28, 2023 at 01:59:40PM +0100, Santiago Vila wrote:
Unsupported by whom? What is supported or unsupported is explained in policy.
Policy says it must work. Therefore it should be supported (by fixing the bugs).
Policy §2.5:
# "required"
# Packages which are necessary for the proper functioning of the
# system (usually, this means that dpkg functionality depends on
# these packages). Removing a "required" package may cause your
# system to become totally broken and you may not even be able to use
# "dpkg" to put things back, so only do so if you know what you are
# doing.
As stated several times now this passage seems wrong, or inaccurate at
best. See #950440. And I don't see how tzdata would ever fall into
this definition even if that paragraph was correct. As mentioned
before, the tzdata package does not seem like a "required" package at
all, and this should be fixed by lowering its priority. Whether
debootstrap can be fixed to not use the Priority workaround, seem
orthogonal to the issue at hand.
That's a straw man. I'm not proposing anything of the sort. Policy says packages must build when essential and build-essential packages
are installed (plus build-dependencies).
Build-essential _packages_. Not the "build-essential" package which very clearly says its dependencies are purely informational.
It does not seem fair to argue both that the build-essential package is
just informational (when it's in fact the canonical declaration of what
is Build-Essential, and what every tool uses to install or check for the Build-Essential package set), and then also argue that whatever
debootstrap installs (which is based both on build-essential plus a workaround due to lack of proper dependency resolution) is the canonical thing.
Regards,
Guillem
On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
...
* Those bugs are RC by definition and have been for a long time.
...
Please provide a pointer where a release team member has said so
explicitly in recent years.
In my experience they are usually saying that FTBFS that do not happen
on the buildds of release architectures are usually not RC.
Indeed. We require that packages are buildable on the buildds. If they
don't and they built before, they are RC buggy. For all other FTBFS
bugs, please use severity important at most.
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.
"Santiago" == Santiago Vila <sanvila@debian.org> writes:
...
The other one: There are a bunch of packages whose unit tests rely on tzdata. The tzdata
package changes often during the lifetime of stable, and as a result, some package might
stop building from source. If we wanted to know in advance which packages might break after
a tzdata update, we could use the available information in the build-depends fields.
...
As you requested, I think the above two are technical reasons, not
merely "because policy says so".
Thanks.
On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
...
The other one: There are a bunch of packages whose unit tests rely on tzdata. The tzdata
package changes often during the lifetime of stable, and as a result, some package might
stop building from source. If we wanted to know in advance which packages might break after
a tzdata update, we could use the available information in the build-depends fields.
...
No, that won't work.
In your builds, how many percent of the packages that did have tzdata installed during the build did not have a direct build dependency?
Looking at the dependency trees, I'd assume the vast majority of
packages where tzdata was installed during the build do not have
a direct build dependency.
El 28/1/23 a las 20:44, Sebastian Ramacher escribió:
On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
...
* Those bugs are RC by definition and have been for a long time.
...
Please provide a pointer where a release team member has said so explicitly in recent years.
In my experience they are usually saying that FTBFS that do not happen
on the buildds of release architectures are usually not RC.
Indeed. We require that packages are buildable on the buildds. If they don't and they built before, they are RC buggy. For all other FTBFS
bugs, please use severity important at most.
So: What am I supposed to do when some maintainer rejects that this is a bug at all and closes the bug? (See #1027364 for an example).
I believe Adam Borowski just does not understand the current build essential definition. Could somebody please explain it to him? I tried and failed.
Also: What I am supposed to do when some maintainer marks the bugs as "unreproducible"?
I think that's completely missing the point on what's the meaning of unreproducible.
El 28/1/23 a las 22:18, Adrian Bunk escribió:
On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
...
The other one: There are a bunch of packages whose unit tests rely on tzdata. The tzdata
package changes often during the lifetime of stable, and as a result, some package might
stop building from source. If we wanted to know in advance which packages might break after
a tzdata update, we could use the available information in the build-depends fields.
...
No, that won't work.
In your builds, how many percent of the packages that did have tzdata installed during the build did not have a direct build dependency?
Looking at the dependency trees, I'd assume the vast majority of
packages where tzdata was installed during the build do not have
a direct build dependency.
I think I see your point, but my idea was not to collect packages
with tzdata in build-depends only, but those whose build-depends
make tzdata to be installed (i.e. including transitive dependencies).
I don't know if there is already a tool for that, nor how much difficult
it would be to have such a tool.
Thanks.
As with all mass bug filings, discuss the issue first on debian-devel.
See developer's reference 7.1.1. This discussion could have both
answered the questions whther RC severity is appropriate for this type
of bug and whether it's a bug at all.
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.
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 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.
Everyone can feel free to disagree with me on the previous paragraph,
but please argue technically and not based on wording in policy.
Sebastian Ramacher <sramacher@debian.org> writes:
As with all mass bug filings, discuss the issue first on debian-devel.
See developer's reference 7.1.1. This discussion could have both
answered the questions whther RC severity is appropriate for this type
of bug and whether it's a bug at all.
Historically, we have not treated FTBFS bugs as falling into the category
of mass bug filing or requiring this pre-discussion. Various folks have
been mass-filing FTBFS bugs near the release freeze for many years now and they generally don't get a debian-devel discussion first.
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.
So, for one, this is getting in the way of making our minimal
(non build) systems smaller.
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,
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).
...
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).
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). […]
`---
...
Regards,
Guillem
What you call current practice is only current debootstrap behaviour.
Johannes Schauer Marin Rodrigues writes:
I think the much more interesting question is in what environment we want to >> build our packages in. Currently, on buildds, we build them in a chroot that >> has Priority:required and build-essential because of (what I think is) a bug in
debootstrap: #837060
I would rather say: The build-essential packages are those installed by debootstrap's buildd profile. At least that seems to be current practice
for a long time.
On 2023-01-28 15:55:05 -0800, Russ Allbery wrote:
Historically, we have not treated FTBFS bugs as falling into the category
of mass bug filing or requiring this pre-discussion. Various folks have
been mass-filing FTBFS bugs near the release freeze for many years now and >> they generally don't get a debian-devel discussion first.
I don't think that those are comparable. Rebuilds with modified base
chroots have been discussed here before filing bugs. [1] is one of the
oldest examples I was able to find.
Cheers
[1] https://lists.debian.org/debian-devel/2008/01/msg00869.html
Hi Andreas,
* Andreas Henriksson <andreas@fatal.se> [2023-01-28 12:50]:
Policy is not a religion. Policy has many bugs. Policy is very outdated. [...]Your argument cuts both ways. Right now, Policy says that
Here's an example you could follow: https://lists.debian.org/debian-policy/2022/12/msg00023.html
the bugs are RC, and if you believe that should be different, why
don't you propose such a change and seek consensus yourself?
Speaking as someone who is doing a lot of QA work, [...]
What is "RC" is defined by the release team, not by policy.My mistake, I conflated policy violation and RC.
The release team has clarified that these bugs are not RC.
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:
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.
Given the number of packages that currently declare a dependency on
tzdata (34~), the ones that seem to have the most potential to pull it
for others are language bindings such as python3-dateutil, python3-tz ruby-tzinfo, etc, which handle timezone stuff anyway and would keep
pulling it. So I find this assertion hard to believe. And the following points seem to be based on this fundamental assumption.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:04:06 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,260 |