At 2025-01-15T14:09:03-0700, Sam Hartman wrote: > >>>>> "G" == G Branden Robinson <g.branden.robin...@gmail.com> writes: > G> Don't we have dpkg filters for this sort of use case? > > I honestly can't tell from your message which position you are > supporting, which I do find somewhat frustrating when I'm trying to > get feedback to make a change.
I'm sorry to frustrate you--the reason you can't discern the direction
of my advocacy on this issue is that I don't have one!
I've been out of practice at Debian packaging for so long that I feel I
now know little, except for that I'd need to (1) spend long hours
perusing the Debian Policy Manual and (2) have an actual need to be
uploading packages on a regular basis to keep my skill current.
> I think that yes, because we have dpkg filters, there's not a
> compelling argument to separate the man pages from the rest of the
> docs.
One thing I didn't say out loud (or type in) is that I'm dubious of the
idea of adding more control fields. Doing that "feels" like an awfully
big hammer for this sort of problem. Having a "Documentation:" control
field as a sort of "Suggests:-for-certain-audiences" seems like it adds
another axis to the linear space of rank 1 upon which we organize
"Depends/Recommends/Suggests".
I seem to remember that Enrico Zini brought us, 20 years ago, a tag
system to attack that exact sort of problem, to keep control fields from
proliferating out of control. I also seem to remember that much more
recently he assessed that initiative as a failure. Even if it was,
that's not a reason to make the mistake he tried to prevent.
> I think that given the multi-arch issues it still makes sense to
> separate the man pages from the m-a: same binaries.
Yes, I think that's a separate concern and much easier to defend.
Corralling architecture-independent data into their own binary packages
pays dividends in a few respects: less archive space consumed and easier
bootstrapping of new architectures (or just ABIs) are a couple that
spring to mind.
> Were it not for multi-arch, I could see an argument that dpkg filters
> were sufficient and the man pages could stay in libpam-modules.
As someone who has a bit of a preoccupation with man pages, I feel
strongly that they should accompany the components of the system they
document. But "accompany" is a term that affords several
interpretations, and this feeling doesn't override my previous
paragraph.
> But I could also see an argument for minimizing the essential set even
> if someone does not use dpkg filters.
I think we should default to shipping documentation, and let people opt
out of receiving it by some means. So if I were LCMNDFL[1], I'd decree
that documentation packages were always Recommended by their binary
counterpart(s).
One of the reasons it's hard to tell which side I've picked, so to
speak, is that I don't feel I'm current with the space of available
solutions in Debian in 2025. I therefore ask what they are.
Regards,
Branden
[1] Leisure-Class, Malignantly Narcissistic Dictator For Life
Too tautologous?
signature.asc
Description: PGP signature
