On Wed, Jan 15, 2025 at 06:03:42PM -0600, G. Branden Robinson wrote:
> I've saved the worst for last.
>
> That is of course docbook-to-man. Ingo and I both find the quality of
> its output to be execrable. It has been unmaintained for many years and
> consistently seems to burn out and drive fro
Quoting Simon McVittie (2025-01-17 10:19:47)
> Many libraries have their API reference as HTML or even PDF, generated
> via something like Doxygen, gtk-doc or Pandoc,
Those packages currently using pandoc are recommended to check if either
of the much lighter cmark or cmark-gfm is sufficient.
-
On Fri, 17 Jan 2025 at 10:56:39 +0900, Simon Richter wrote:
> basically we'd have to give every -dev package containing
> manual pages a -doc package
In many cases I think this is best-practice anyway, because it takes
the documentation generation toolchain out of the critical path for
bootstrappi
Hi,
On 1/17/25 05:14, Sam Hartman wrote:
With the exception of Simon Richter, we appear to be agreed that
avoiding man pages in m-a: same packages is good.
I mean, this is specifically about the manpages included in
libpam-modules, which are at the intersection of
- likely to be useful wh
> "Simon" == Simon McVittie writes:
Simon> On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
>> (We'd also need to do something about libpam0g-dev man pages).
Simon> Moving user-facing documentation from libpam0g into either
Simon> libpam-modules-bin or libpam-doc (de
> "Simon" == Simon Richter writes:
Simon> Hi,
Simon> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook
>> tools changed between one arch build and another, we'd end up
>> with m-a uninstallable packages.
Simon>
Bálint Réczey writes:
> On 2025. Jan 16., Thu at 8:17, Simon Richter wrote:
>> Agreed, it's not a complete fix, but I'd expect the frequency of
>> changes in the output besides the version number to be low enough for
>> this to be the least-effort solution.
>> If it means we need to trigger a r
On Thu, 16 Jan 2025 at 09:41:51 -0700, Sam Hartman wrote:
> (We'd also need to do something about libpam0g-dev man pages).
Moving user-facing documentation from libpam0g into either
libpam-modules-bin or libpam-doc (depending how often you expect users to
need it), and developer documentation from
> "Guillem" == Guillem Jover writes:
Guillem> Hi!
Guillem> On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
>> My proposal is to move the man pages into libpam-doc. I'm not
>> actually convinced that normal Debian users need man pages for
>> all the pam modules on
[Please don't CC me]
* Sam Hartman [250115 14:45]:
> Do you actually have a system on which you want these man pages and on
> which the extra space of libpam-doc would be a problem?
No.
> Unless there's a compelling need, my answer is that I don't understand
> why manpages should be separated f
Hi!
On Wed, 2025-01-15 at 09:43:36 -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.
> If people
Hi,
On 2025. Jan 16., Thu at 8:17, Simon Richter wrote:
> Hi,
>
> On 1/16/25 13:22, Russ Allbery wrote:
>
> > There are various things one can do to try to make the output of a man
> > page generator like that more consistent, but they don't fix the problem,
> > just reduce its frequency, unless
Hi Sam,
On Wed, Jan 15, 2025 at 09:43:36AM -0700, Sam Hartman wrote:
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pages for
> all the pam modules on all Debian systems, and a suggests relationship
> should be sufficient.
I'
Hi,
On 1/16/25 13:22, Russ Allbery wrote:
There are various things one can do to try to make the output of a man
page generator like that more consistent, but they don't fix the problem,
just reduce its frequency, unless Debian sets up to do a fully
reproducible build with pinned versions of ev
Simon Richter writes:
> On 1/16/25 01:43, Sam Hartman wrote:
>> For a while we just built the man pages but if any of the docbook tools
>> changed between one arch build and another, we'd end up with m-a
>> uninstallable packages.
> Can this be fixed by removing the "Generator:" comment in the g
Hi,
On 1/16/25 01:43, Sam Hartman wrote:
For a while we just built the man pages but if any of the docbook tools
changed between one arch build and another, we'd end up with m-a
uninstallable packages.
Can this be fixed by removing the "Generator:" comment in the generated
manpage, and possi
"G. Branden Robinson" writes:
> 1. podlators/Pod::Man -- a proud exception to some of the
> generalizations above. First, it's been around probably longer than
> any of these others, maybe by a margin of decades. Second, it was
> initially developed by people who seemed to have a g
Hi Jonathan,
At 2025-01-15T22:01:28+, Jonathan Dowland wrote:
> On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
> > As someone who has a bit of a preoccupation with man pages
>
> You've reminded me that you presented 'Write the Fine Manual' in 2005,
> (possibly at DebConf?).
I
On Wed Jan 15, 2025 at 9:42 PM GMT, G. Branden Robinson wrote:
As someone who has a bit of a preoccupation with man pages
You've reminded me that you presented 'Write the Fine Manual' in 2005,
(possibly at DebConf?). I thought it was a really good slide-deck, but
it's either unavailable or at
At 2025-01-15T14:09:03-0700, Sam Hartman wrote:
> > "G" == G Branden Robinson 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 f
Sam Hartman writes:
> My proposal is to move the man pages into libpam-doc. I'm not actually
> convinced that normal Debian users need man pages for all the pam
> modules on all Debian systems, and a suggests relationship should be
> sufficient. If people really want to maintain the current level
> "G" == G Branden Robinson writes:
G> At 2025-01-15T12:45:22-0700, Sam Hartman wrote:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the addi
At 2025-01-15T12:45:22-0700, Sam Hartman wrote:
> Marvin> I have on a number of occasions used these man pages, and
> Marvin> having them installed locally is very helpful. I would
> Marvin> rather have the man pages installed without the additional
> Marvin> documentation in libpa
> "Marvin" == Marvin Renich writes:
Marvin> I have on a number of occasions used these man pages, and
Marvin> having them installed locally is very helpful. I would
Marvin> rather have the man pages installed without the additional
Marvin> documentation in libpam-doc. Why n
* Sam Hartman [250115 11:44]:
>
> TL;DR: I propose move man pages out of a multi-arch: same package into a
> arch all package. Asking for any downsides and usrmerge review.
>
> My proposal is to move the man pages into libpam-doc.
> I'm not actually convinced that normal Debian users need man pa
25 matches
Mail list logo
