Bug#1029831: debian-policy: Make required packages build-essential
On Sat, 2023-01-28 at 14:07:06 +0100, Ansgar wrote:
> Timo Röhling writes:
> > * Andreas Henriksson <andreas@fatal.se> [2023-01-28 12:50]:
> >>Policy is not a religion. Policy has many bugs. Policy is very outdated.
> >>[...]
> >>Here's an example you could follow:
> >>https://lists.debian.org/debian-policy/2022/12/msg00023.html
> > Your argument cuts both ways. Right now, Policy says that
> > the bugs are RC, and if you believe that should be different, why
> > don't you propose such a change and seek consensus yourself?
>
> I don't think it does. Policy doesn't specify what packages actually
> are build-essential; it only refers to an "informational list" in
> Section 4.2.
It does, but in a way that does not require encoding package names in
policy to leave breathing room to toolchain maintainers.
Policy says this:
,---
It is not necessary to explicitly specify build-time relationships on
a minimal set of packages that are always needed to compile, link and
put in a Debian package a standard “Hello World!” program written in C
or C++. The required packages are called *build-essential*, and an
informational list can be found in "/usr/share/doc/build-
essential/list" (which is contained in the "build-essential" package).
[1]
`---
With that footnote explaining the rationale:
,---
[1] Rationale:
* This allows maintaining the list separately from the policy
documents (the list does not need the kind of control that the
policy documents do).
* Having a separate package allows one to install the build-
essential packages on a machine, as well as allowing other
packages such as tasks to require installation of the build-
essential packages using the depends relation.
* The separate package allows bug reports against the list to be
categorized separately from the policy management process in the
BTS.
`---
And further down it says this:
,---
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 think discussion in #1027832 suggested that required packages should
> be build-essential as well. Maybe this should be made explicit, for
> example by changing
>
> +---
> | The required packages are called build-essential, and an informational
> | list can be found in /usr/share/doc/build-essential/list (which is
> | contained in the build-essential package).
> +---[ Section 4.2 ]
>
> to something like
>
> +---
> | The required packages are called build-essential, and include packages
> | with Priority "required" and additional packages. An informational
> | list of additional packages can be found in
> | /usr/share/doc/build-essential/list (which is contained in the
> | build-essential package).
> +---
>
> This only documents existing practice as practically all systems have
> required packages installed.
If the point of this proposal is to include tzdata by proxy, then that
makes no sense, because tzdata does not have the properties to keep
being a "required" package. And if Priority "required" packages are
a way to denote the pseudo-essential set via priorities (even though we
do not even mark depended libraries as such anymore, so it's at most a
subset) instead of the Essential:yes field and dependencies of those,
then this is already covered by the "essential" mention above.
So adding this would only confuse things more than help anything. And
would be only a definition hack to preserve tzdata in that set only
temporarily anyway.
Guillem
Reply to: