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

Felix Lechner <felix.lechner@lease-up.com> writes:

Hi Felix;

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.

Hi David,

Without sections my request would go away, but that's as much of a
side as I will take.

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

Hi David,
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