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
On Wed, Jan 15, 2025 at 06:24:39PM -0500, Gioele Barabucci wrote:
> On 15/01/25 17:43, 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 suggest
[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
On 15/01/25 17:43, 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.
Unrelated to the question at hand, but
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.
I'm in the process of packaging pam 1.7.0. Upstream has moved from
autotools to meson and in the process has streamlined their release
tarballs to remove all or
28 matches
Mail list logo
