[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: man_MANS install locations

From: Jacob Bachmeyer
Subject: Re: man_MANS install locations
Date: Wed, 31 Aug 2022 18:53:32 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 SeaMonkey/1.1.17 Mnenhy/

Karl Berry wrote:
Hi Jan,

    As for GNU/Linux, what was the rationale to only permit [0-9ln]?

No idea. Maybe just didn't think about "m", or maybe it didn't exist at
that time? Jim, Paul, anyone?

Should automake be relaxed?
I see no harm in allowing more (any) letters, if that's what you mean.

    When running automake on Solaris, placing svcadm.1m into man1 rather
    than man1m seems outright wrong.

But is Automake's purpose to reproduce platform-specific behavior, or to
have consistent behavior across platforms?  I think the latter.

This would be adapting to platform-specific requirements. I suspect that Solaris man(1) will not look for svcadm.1m in man1 at all but only in man1m.

I guess a new option to install *.1m in man1m/, etc., would be ok, if
you want it. If you or anyone can provide a patch, that would be
great. Unfortunately I doubt it's anything I will ever implement myself.

Maybe the best answer is to install into an existing directory if one is found and otherwise trim the suffix to the "standard" set?

    Should the rpmlint check be adjusted to cater to the GNU FHS?

I guess that's a question for the rpmlint people, whoever they are.
I don't see that Automake's default behavior is going to change.

Also, GNU (as an organization) never had anything to do with the FHS,
so far as I know. I don't think the GNU coding standards/maintainer
information have anything to say about this topic ...

I seem to remember reading somewhere that /usr is supposed to be a symlink to / on the GNU system, so no, GNU is not intended to follow FHS.

-- Jacob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]