Bug#1029831: debian-policy: Make required packages build-essential
On Sun, 2023-01-29 at 13:53 +0100, Santiago Vila wrote:
> What you call current practice is only current debootstrap behaviour.
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
Bug#1029831: debian-policy: Make required packages build-essential
El 28/1/23 a las 14:07, Ansgar escribió: +--- | 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. (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.
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 [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
Bug#1029831: debian-policy: Make required packages build-essential
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. signature.asc Description: PGP signature
Bug#1029831: debian-policy: Make required packages build-essential
Package: debian-policy [ This is basically #1027832 ] Timo Röhling writes: > * Andreas Henriksson [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. 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
