Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#998282: Please make Section a required field for the source paragraph in d/control
1 view
Skip to first unread message
Felix Lechner
Nov 1, 2021, 3:50:05 PM11/1/21
to
Package: debian-policy
Hi,
The installable stanzas in d/control (called "binary package
paragraphs" in policy) inherit the Section field from the source
paragraph. There is no reason to provide inheritance the other way
around.
Also, sources may not build successfully on all architectures. People
do not often use Debian's sources directly, but we distribute them
just like installation packages.
The Section field in the source paragraph (called "general paragraph"
in policy) reveals important clues about the DFSG-classification of
the sources. It should be required. Policy section 5.2 presently shows
the field as merely recommended. Thanks!
Kind regards
Felix Lechner
Hi,
The installable stanzas in d/control (called "binary package
paragraphs" in policy) inherit the Section field from the source
paragraph. There is no reason to provide inheritance the other way
around.
Also, sources may not build successfully on all architectures. People
do not often use Debian's sources directly, but we distribute them
just like installation packages.
The Section field in the source paragraph (called "general paragraph"
in policy) reveals important clues about the DFSG-classification of
the sources. It should be required. Policy section 5.2 presently shows
the field as merely recommended. Thanks!
Kind regards
Felix Lechner
David Bremner
Nov 4, 2021, 10:20:03 AM11/4/21
to
So, you probably know my biases. I think Debian would be better off if
we eliminated sections, with potential exceptions for where they are
needed by tooling (debian-installer might be such a case, it isn't
really clear to from the discussion I read so far). I would be fine with
mandating some indication of debian archive area in the source as well
as binary packages. That's just my personal view, and probably doesn't
(and shouldn't) weigh too much in the policy review.
On the other hand, what is not just my personal opinion is that policy
should follow practice, and policy changes should generally not make a
large number of packages buggy. So, do you have some numbers for how
widespread the adoption of this idea is? Usually I would suggest that
someone with an idea like this (assuming some degree of project
concensus) should start with a lintian check. I assume you are aware of
this, but you don't mention in your message whether such a check exists,
and if not why not (does it not make sense for some reason?).
Finally, I would suggest you consult with the ftp-master team about how
they feel about the potential extra work managing overrides for source
packages, and if there are any technical/process issues preventing
adoption of this policy.
Felix Lechner
Nov 4, 2021, 4:30:04 PM11/4/21
to
Hi David,
On Thu, Nov 4, 2021 at 7:14 AM David Bremner <da...@tethera.net> wrote:
>
> I think Debian would be better off if
> we eliminated sections
Without sections my request would go away, but that's as much of a
side as I will take.
> do you have some numbers
Thank you for that idea! I added a Lintian classification tag for it
[1] and will answer that question shortly.
Kind regards
Felix Lechner
P.S. I would be happy to add additional tags for statistics if they
are helpful to your cause.
[1] https://salsa.debian.org/lintian/lintian/-/commit/bc48c6e2114c1cf9ca143db3ad9b6068ddca791d
On Thu, Nov 4, 2021 at 7:14 AM David Bremner <da...@tethera.net> wrote:
>
> I think Debian would be better off if
> we eliminated sections
side as I will take.
> do you have some numbers
[1] and will answer that question shortly.
Kind regards
Felix Lechner
P.S. I would be happy to add additional tags for statistics if they
are helpful to your cause.
[1] https://salsa.debian.org/lintian/lintian/-/commit/bc48c6e2114c1cf9ca143db3ad9b6068ddca791d
Felix Lechner
Nov 5, 2021, 9:00:03 PM11/5/21
to
> do you have some numbers
According to Lintian [1] all sources among the 33,721 sources in
unstable and experimental—except perhaps the ones listed below—have a
Section field in the source stanza of d/control. [2]
You can see for yourself by querying our JSON interface [3] with this command:
wget -O no-source-section.hints
'https://lintian.debian.net/query/contexts?tag=no-source-section'
It returns an empty array: []
The following sources were not checked (for resource reasons):
- firefox
- firefox-esr
- linux
- llvm-toolchain-9
- llvm-toolchain-10
- llvm-toolchain-11
- llvm-toolchain-snapshot
- nvidia-cuda-toolkit
- thunderbird
I believe the tag functions properly because there is a unit test for
it. [4] [5]
Kind regards
Felix Lechner
[1] https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Control/Field/Section.pm
[2] https://lintian.debian.org/tags/no-source-section
[3] https://lintian.debian.org/query
[4] https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/build-spec/debian/control.in
[5] https://salsa.debian.org/lintian/lintian/-/blob/master/t/recipes/checks/debian/control/field/section/no-section-in-source-stanza/eval/hints
Russ Allbery
Sep 20, 2022, 10:40:03 PM9/20/22
to
Felix Lechner <felix....@lease-up.com> writes:
> The installable stanzas in d/control (called "binary package paragraphs"
> in policy) inherit the Section field from the source paragraph. There is
> no reason to provide inheritance the other way around.
Huh, this pointed out to me that I don't know what the current behavior
> The installable stanzas in d/control (called "binary package paragraphs"
> in policy) inherit the Section field from the source paragraph. There is
> no reason to provide inheritance the other way around.
is. I think I've always put a Section field in the first stanza and then
overridden it as necessary, or at least I don't remember thinking about
this before.
The current Policy description of the Section field is rather cryptic:
This field specifies an application area into which the package has
been classified. See Sections.
When it appears in the debian/control file, it gives the value for the
subfield of the same name in the Files field of the .changes file. It
also gives the default for the same field in the binary packages.
I understand what it's trying to say, but that's a very mechanical
definition that isn't clear about the relationship between the Section
field in the source stanza and the Section field in the binary stanzas.
(It also claims Section is about an "application area," a term that I
don't think we use anywhere else in Policy.)
So, what happens today if you put Section in a binary stanza but not in
the source stanza? Is it inherited from the binary stanza by the source
stanza (I agree that seems weird)? If so, from which binary stanza is it
inherited, if there are several? The definition of the Files field
implies that the section may just be - in some cases.
The current documentation certainly seems inadequate, although I'd like to
understand what the behavior of Debian software is before proposing
alternative wording.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Guillem Jover
Sep 22, 2022, 7:40:03 PM9/22/22
to
Hi!
On Tue, 2022-09-20 at 19:36:36 -0700, Russ Allbery wrote:
> Felix Lechner <felix....@lease-up.com> writes:
> > The installable stanzas in d/control (called "binary package paragraphs"
> > in policy) inherit the Section field from the source paragraph. There is
> > no reason to provide inheritance the other way around.
>
> Huh, this pointed out to me that I don't know what the current behavior
> is. I think I've always put a Section field in the first stanza and then
> overridden it as necessary, or at least I don't remember thinking about
> this before.
If you omit the field in the source stanza, then both dpkg-genchanges
and lintian will complain about it with a warning.
> The current Policy description of the Section field is rather cryptic:
>
> This field specifies an application area into which the package has
> been classified. See Sections.
>
> When it appears in the debian/control file, it gives the value for the
> subfield of the same name in the Files field of the .changes file. It
> also gives the default for the same field in the binary packages.
>
> I understand what it's trying to say, but that's a very mechanical
> definition that isn't clear about the relationship between the Section
> field in the source stanza and the Section field in the binary stanzas.
> (It also claims Section is about an "application area," a term that I
> don't think we use anywhere else in Policy.)
>
> So, what happens today if you put Section in a binary stanza but not in
> the source stanza? Is it inherited from the binary stanza by the source
> stanza (I agree that seems weird)? If so, from which binary stanza is it
> inherited, if there are several? The definition of the Files field
> implies that the section may just be - in some cases.
Some of the fields found in the debian/control binary stanzas inherit
their values (if omitted) from the source stanza, otherwise they get
overridden.
The binary packages use a combination of information from
debian/changelog, the source stanza and their own binary stanza.
For non-binary packages (sources) or artifacts (say .buildinfo, or
byhand objects) there are no binary stanzas, so no information is
taken from them.
If you specify a Section field for every binary stanza, and omit it
from the source stanza, then dpkg-genchanges will have to fill it with
«-» when generating the .changes file.
If you omit the Section field from both the source stanza and one of
the binary stanzas, then that binary package will contain no Section
field, dpkg-genchanges will warn about both missing fields, and it
will fill the section value as «-» for that binary package on the
.changes file.
Thanks,
Guillem
On Tue, 2022-09-20 at 19:36:36 -0700, Russ Allbery wrote:
> Felix Lechner <felix....@lease-up.com> writes:
> > The installable stanzas in d/control (called "binary package paragraphs"
> > in policy) inherit the Section field from the source paragraph. There is
> > no reason to provide inheritance the other way around.
>
> Huh, this pointed out to me that I don't know what the current behavior
> is. I think I've always put a Section field in the first stanza and then
> overridden it as necessary, or at least I don't remember thinking about
> this before.
and lintian will complain about it with a warning.
> The current Policy description of the Section field is rather cryptic:
>
> This field specifies an application area into which the package has
> been classified. See Sections.
>
> When it appears in the debian/control file, it gives the value for the
> subfield of the same name in the Files field of the .changes file. It
> also gives the default for the same field in the binary packages.
>
> I understand what it's trying to say, but that's a very mechanical
> definition that isn't clear about the relationship between the Section
> field in the source stanza and the Section field in the binary stanzas.
> (It also claims Section is about an "application area," a term that I
> don't think we use anywhere else in Policy.)
>
> So, what happens today if you put Section in a binary stanza but not in
> the source stanza? Is it inherited from the binary stanza by the source
> stanza (I agree that seems weird)? If so, from which binary stanza is it
> inherited, if there are several? The definition of the Files field
> implies that the section may just be - in some cases.
their values (if omitted) from the source stanza, otherwise they get
overridden.
The binary packages use a combination of information from
debian/changelog, the source stanza and their own binary stanza.
For non-binary packages (sources) or artifacts (say .buildinfo, or
byhand objects) there are no binary stanzas, so no information is
taken from them.
If you specify a Section field for every binary stanza, and omit it
from the source stanza, then dpkg-genchanges will have to fill it with
«-» when generating the .changes file.
If you omit the Section field from both the source stanza and one of
the binary stanzas, then that binary package will contain no Section
field, dpkg-genchanges will warn about both missing fields, and it
will fill the section value as «-» for that binary package on the
.changes file.
Thanks,
Guillem
0 new messages