[ This is basically #1027832 ]

Timo Röhling writes:

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.

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.

Ansgar

    Ansgar> +--- | The required packages are called build-essential, and
    Ansgar> an informational | list can be found in
    Ansgar> /usr/share/doc/build-essential/list (which is | contained in
    Ansgar> the build-essential package).  +---[ Section 4.2 ]

    Ansgar> to something like

    Ansgar> +--- | The required packages are called build-essential, and
    Ansgar> include packages | with Priority "required" and additional
    Ansgar> packages. An informational | list of additional packages can
    Ansgar> be found in | /usr/share/doc/build-essential/list (which is
    Ansgar> contained in the | build-essential package).  +---

    Ansgar> This only documents existing practice as practically all
    Ansgar> systems have required packages installed.

I support this change and would second if submitted as a patch.

    Ansgar> +--- | The required packages are called build-essential, and
    Ansgar> an informational | list can be found in
    Ansgar> /usr/share/doc/build-essential/list (which is | contained in
    Ansgar> the build-essential package).  +---[ Section 4.2 ]

    Ansgar> to something like

    Ansgar> +--- | The required packages are called build-essential, and
    Ansgar> include packages | with Priority "required" and additional
    Ansgar> packages. An informational | list of additional packages can
    Ansgar> be found in | /usr/share/doc/build-essential/list (which is
    Ansgar> contained in the | build-essential package).  +---

    Ansgar> This only documents existing practice as practically all
    Ansgar> systems have required packages installed.

I support this change and would second if submitted as a patch.

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). […]
  `---

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

El 28/1/23 a las 14:07, Ansgar escribió:

(I replied in -devel but should have replied here).

What you call current practice is only current debootstrap behaviour.

There are already packages in bullseye having build-depends
on tzdata, and afaik it was not me who reported them to have such
build-dependency. If current practice was really not to consider
tzdata as build-essential, as you say, somebody would have reported
those build-dependencies as a bug, because we don't use build-depends
when the package is build-essential.

I would say, therefore, that current practice all this time has really
been to report those bugs and fix them, i.e. current practice is
that tzdata is not build-essential, despite debootstrap behaviour.

Thanks.

Then I'll reply here as well (content is the same as -devel):

Current practice is to use Build-Depends to specify build dependencies
in a way that the buildd network will successfully build packages. The
data might also be of (limited) use for other purposes.

We do *not* specify additional Build-Conflicts (that might make builds
fail / produce different results). Neither does the buildd network
require that packages already installed are listed additionally in
Build-Depends to install those and build packages successfully.

The set of preinstalled packages in build environments is decided by
the debootstrap implementation, so yes, the debootstrap behavior is
current practice.

If you want Build-{Depends,Conflicts} to provide stronger promises,
that is a change from current practice. And could be extended to
forcing /usr/local to be empty and a sane, standard environment and
contents of $HOME and anything else that could affect build results.

Ansgar

* Ansgar <ansgar@43-1.org> [2023-01-29 14:01]:

Note that debootstrap changed and now only installs essential,
build-essential and apt in the buildd variant for trixyie and later (see
#837060). Note that the Debian buildds additionally have openssl and
ca-certificates installed by default. On the other side
dpkg-genbuildinfo does not add apt, openssl and ca-certificates to the
buildinfo file if they are not a Build-Dependency. This means that
packages that rely on them being present by default fail to build
reproducible with debrebuild. The reproducible builds people have filled
bugs in those cases and the sbuild team has sketches how to drop those
three packages from the build environment.

In essence I think we should not extend the build-essential set by
policy but rather try to reduce it more.

Cheers Jochen

Indeed, such fact by itself makes this policy proposal to be obsolete.

We have finally fixed debootstrap to match policy (regarding required packages).
Now they are in sync. Now we don't need to change policy anymore "so
that deboostrap and policy are in sync".

Thanks.

What I meant here is that given that debootstrap changed the algorithm
to not install many required packages "just because they are required",
we are now a lot closer to have policy and debootstrap in sync,
without having to make required packages build-essential.

Thanks.

Hi!

I think this report should be closed because it is based on an invalid
premise.

Whether the description of Priority:required needs to be updated,
and/or whether Priority:required should be changed to map to
Essential:yes is already tracked in #452393 and #950440.

Thanks,
Guillem