11:10 a.m.
Hi,
A question:
Are packages legitimated to install man pages into
arbitrary /usr/share/man/man* directories outside those provided by the
"filesystem" package?
Background:
- the man-pages rpm installs its man-pages into
/usr/share/man/man0p
/usr/share/man/man1p
/usr/share/man/man3p
- the blas and lapack rpms install into
/usr/share/man/manl
Additionally, all these packages leave their man page installation
directories unowned:
# rpm -qf /usr/share/man/man?p /usr/share/man/manl
file /usr/share/man/man0p is not owned by any package
file /usr/share/man/man1p is not owned by any package
file /usr/share/man/man3p is not owned by any package
file /usr/share/man/manl is not owned by any package
I checked the FHS, but it once again seems intentionally vague to me
wrt. this topic, so I think we need a convention, here.
Ralf
12:09 p.m.
On Tue, 2005-09-27 at 18:10 +0200, Ralf Corsepius wrote:
Hi,
A question:
Are packages legitimated to install man pages into
arbitrary /usr/share/man/man* directories outside those provided by the
"filesystem" package?
Short answer: Yes, but only in specific cases.
I checked the FHS, but it once again seems intentionally vague to me
wrt. this topic, so I think we need a convention, here.
OK... so the FHS says:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
"Manual pages are stored in
<mandir>/<locale>/man<section>/<arch>."
Where <mandir> = /usr/share/man
"Systems which use a unique language and code set for all manual pages
may omit the <locale> substring and store all manual pages in <mandir>.
For example, systems which only have English manual pages coded with
ASCII, may store manual pages (the man<section> directories) directly
in /usr/share/man. (That is the traditional circumstance and
arrangement, in fact.)"
"Similarly, provision must be made for manual pages which are
architecture-dependent, such as documentation on device-drivers or
low-level system administration commands. These must be placed under an
<arch> directory in the appropriate man<section> directory; for example,
a man page for the i386 ctrlaltdel(8) command might be placed
in /usr/share/man/<locale>/man8/i386/ctrlaltdel.8."
Or, to put it in plain english:
If you have man pages that are only in EN (the most common case), then
you need to put them in %{_mandir}/man<section>, where the section
matches the section in the man pages. This is what lapack/blas does.
If you have man pages that are provided in multiple locales, then they
need to be put in %{_mandir}/<locale>/man<section>, where the locale and
section matches the section in the man pages. Man does this for some of
its translated man pages.
If you have man pages that are architecture-dependent (aka, only true
for a specific architecture), then they should be placed in
%{_mandir}/<locale>/man<section>/<arch>. I'm not aware of anything
doing
this, but this is not surprising, since this is a very obscure case.
FE Packages should not own any directories under %{_mandir}. I'm also
aware that many directories under /usr/share/man are not owned. This
should be filed as a bug against the "man" package, IMHO, but this seems
to be a point of much contention inside Red Hat.
Again, I can't control FC packaging policy (unfortunately), just FE. If
nothing else, we'll set a good example for Red Hat.
~spot
--
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!
9 p.m.
On Tue, 2005-09-27 at 12:09 -0500, Tom 'spot' Callaway wrote:
On Tue, 2005-09-27 at 18:10 +0200, Ralf Corsepius wrote:
> Hi,
>
> A question:
>
> Are packages legitimated to install man pages into
> arbitrary /usr/share/man/man* directories outside those provided by the
> "filesystem" package?
Short answer: Yes, but only in specific cases.
> I checked the FHS, but it once again seems intentionally vague to me
> wrt. this topic, so I think we need a convention, here.
OK... so the FHS says:
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES
"Manual pages are stored in
<mandir>/<locale>/man<section>/<arch>."
Where <mandir> = /usr/share/man
"Systems which use a unique language and code set for all manual pages
may omit the <locale> substring and store all manual pages in <mandir>.
For example, systems which only have English manual pages coded with
ASCII, may store manual pages (the man<section> directories) directly
in /usr/share/man. (That is the traditional circumstance and
arrangement, in fact.)"
"Similarly, provision must be made for manual pages which are
architecture-dependent, such as documentation on device-drivers or
low-level system administration commands. These must be placed under an
<arch> directory in the appropriate man<section> directory; for example,
a man page for the i386 ctrlaltdel(8) command might be placed
in /usr/share/man/<locale>/man8/i386/ctrlaltdel.8."
Or, to put it in plain english:
If you have man pages that are only in EN (the most common case), then
you need to put them in %{_mandir}/man<section>, where the section
matches the section in the man pages. This is what lapack/blas does.
If you have man pages that are provided in multiple locales, then they
need to be put in %{_mandir}/<locale>/man<section>, where the locale and
section matches the section in the man pages. Man does this for some of
its translated man pages.
If you have man pages that are architecture-dependent (aka, only true
for a specific architecture), then they should be placed in
%{_mandir}/<locale>/man<section>/<arch>. I'm not aware of anything
doing
this, but this is not surprising, since this is a very obscure case.
FE Packages should not own any directories under %{_mandir}.
That's the crucial point.
IMO, packages must own directories if they install their manpages
outside of those directories provided by "filesystem".
I'm also
aware that many directories under /usr/share/man are not owned. This
should be filed as a bug against the "man" package, IMHO, but this seems
to be a point of much contention inside Red Hat.
Again, I can't control FC packaging policy (unfortunately), just FE. If
nothing else, we'll set a good example for Red Hat.
blas and lapack are FE packages.
Ralf
1:36 a.m.
On Wednesday 28 September 2005 10:00, Ralf Corsepius wrote:
IMO, packages must own directories if they install their manpages
outside of those directories provided by "filesystem".
Just thought I'd throw my 2c in here: making sure that there is a 1:1
mapping for pkg to directory is a bit pedantic. What problem are we
(as in packagers) actually trying to solve?
rmdir will always fail upon package removal if a directory is in the
%files section. This is silent and not visible to the user.
Requires based on directories are founded on a fragile footing. If
requires based on directories were sufficiently robust, then, things
like python-abi or python(abi) never really needed to come out of the
framework.
Thoughts?
--
-jeff
1:55 a.m.
On Wed, 2005-09-28 at 14:36 +0800, Jeff Pitman wrote:
On Wednesday 28 September 2005 10:00, Ralf Corsepius wrote:
> IMO, packages must own directories if they install their manpages
> outside of those directories provided by "filesystem".
Just thought I'd throw my 2c in here: making sure that there is a 1:1
mapping for pkg to directory is a bit pedantic.
That's not the problem, ...
the problem is "unowned files/dirs" ...
What problem are we
(as in packagers) actually trying to solve?
... the problem is "unowned
files/dirs contradict maintainability".
As RH handles directories pretty lax, when looking closely into your
system, you permanently find unowned files and directories, and
permanently are facing the question like
* Is this empty directory still in use or did a temporarily/formerly
installed package leave it around?
* What has caused this dangling symlink?
* Where does this unowned file stem from?
etc. etc.
To check, you'd normally apply "rpm -qf <dir>". However due to
RH's
policy this is of very limited use and forces you to dig deeply into
your file system.
rmdir will always fail upon package removal if a directory is in the
%files section. This is silent and not visible to the user.
That's news to me
- How that?
I aware that rpm has problems in scheduling directory removals and
scheduling multiple package removals, which can cause "rmdir" to fail
sometimes, because they are not handled in correct order.
But in any case, rpm should be able to handle "rpm -e <one package>"
correctly.
Ralf
11:03 p.m.
On Tue, 2005-09-27 at 20:41 -0700, Michael A. Peters wrote:
On Tue, 2005-09-27 at 12:09 -0500, Tom 'spot' Callaway
wrote:
> I'm not aware of anything doing
> this, but this is not surprising, since this is a very obscure case.
and I think would be better handled better %ifarch ...
Nevermind - I'm an idiot - /usr/share is often nfs mounted.
6785
days inactive
6786
days old
packaging@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Jeff Pitman -
Michael A. Peters -
Ralf Corsepius -
Tom Callaway