Hi! On Sun, 2023-01-29 at 00:45:00 +0100, Guillem Jover wrote: > On Sat, 2023-01-28 at 14:07:06 +0100, Ansgar wrote: > > Timo Röhling writes: > > > * Andreas Henriksson <[email protected]> [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.
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
