Bug 220265 - Many unowned directories in /usr/share/man
Many unowned directories in /usr/share/man
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: filesystem (Show other bugs)
11
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
bzcl34nup
:
: 510359 (view as bug list)
Depends On: 510357 510359 510360 510361 510362 510363 510364 510365 510366
Blocks: FC7Target
  Show dependency treegraph
 
Reported: 2006-12-19 18:22 EST by Robert Scheck
Modified: 2009-10-20 04:54 EDT (History)
8 users (show)

See Also:
Fixed In Version: filesystem-2.4.28-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-20 04:54:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2006-12-19 18:22:51 EST
Description of problem:
There are many unowned directories in /usr/share/man, e.g.

/usr/share/man/fr/man3
/usr/share/man/hu/man1
/usr/share/man/hu/man8
/usr/share/man/id/man8
/usr/share/man/it/man3
/usr/share/man/pl/man7
/usr/share/man/pt_BR
/usr/share/man/pt_BR/man1
/usr/share/man/pt_BR/man5
/usr/share/man/ru/man1
/usr/share/man/ru/man3
/usr/share/man/ru/man5
/usr/share/man/ru/man8
/usr/share/man/sk/man8
/usr/share/man/tr/man1
/usr/share/man/tr/man5
/usr/share/man/tr/man8
/usr/share/man/zh_CN/man1
/usr/share/man/zh_CN/man8
/usr/share/man/zh_TW/man1
/usr/share/man/zh_TW/man8

on my system.

Version-Release number of selected component (if applicable):
man-1.6d-3
man-pages-2.43-2

Actual results:
Many unowned directories in /usr/share/man

Expected results:
Owned directories by man or man-pages, as Rex told in bug #196669 comment #17

Additional info:
If this bug needs to be re-assigned to man-pages or filesystem, please do so.
Comment 2 Rex Dieter 2007-01-26 08:30:54 EST
Phil, somebody needs to own these dirs.  Do you have an opinion on whether it
should be here (man) or in filesystem?
Comment 3 Phil Knirsch 2007-01-26 08:49:27 EST
A few of them would be clear candidates for man-pages-LANG imo:

/usr/share/man/fr/man3: man-pages-fr-2.39-7.fc7.noarch.rpm
/usr/share/man/it/man3: man-pages-it-0.3.0-17.1.noarch.rpm
/usr/share/man/pl/man7: man-pages-pl-0.24-2.1.noarch.rpm
/usr/share/man/ru/man1: man-pages-ru-0.97-1.1.1.noarch.rpm
/usr/share/man/ru/man3: man-pages-ru-0.97-1.1.1.noarch.rpm
/usr/share/man/ru/man5: man-pages-ru-0.97-1.1.1.noarch.rpm
/usr/share/man/ru/man8: man-pages-ru-0.97-1.1.1.noarch.rpm

About the rest it's a tricky question. I personally see 3 possibilities:

1) Put them in filesystem
2) Put them in man-pages main package
3) Create subpackages for each missing language and put them in there


1) and 2) aren't really the correct solutions though. 1) as filesystem isn't and
shouldn't be related with languages and 2) because just dumping them in the
man-pages is just not correct if we already have subpackages for other langauges.

So i'd say we should go with 3 and put the ones i've listed above in the
corresponding already existing man-pages-LANG packages.

Read ya, Phil
Comment 4 Ivana Varekova 2007-01-26 09:07:59 EST
There are man pages which are in /usr/share/man/LANG/man* and which are not in
man-pages-LANG (they are part of documentation of some package). There is no
need to install man-pages-LANG. There should be added the dependency to
man-pages-LANG to all packages having a man pages in these directories.
I think man-pages-LANG should not be the owner. 
Perhaps filesystem would be better candidate for this directories. 
Comment 5 Phil Knirsch 2007-01-26 09:09:48 EST
As Ivana doesn't like the idea of putting them into the man-pages package and i
don't think filesystem is the right spot i'm closing this bug as wontfix for now.

Read ya, Phil
Comment 6 Robert Scheck 2007-01-26 09:25:17 EST
Sorry, but WONTFIX sounds to me like I'm to lazy to fix this bug, because there
should be NEVER ANY unowned directory in Core to like it is forced for Extras.
I'll reopen this bug report until the hell freezes or the problem is solved by
owning the directories at man-pages, filesystem or anything better.
Comment 7 Robert Scheck 2007-03-24 19:13:56 EDT
Ping?
Comment 8 Robert Scheck 2007-04-03 18:43:14 EDT
The following directories are not owned, too:

 - /usr/share/man/man0p
 - /usr/share/man/man1p
 - /usr/share/man/man3p

they were owned by man-pages, but Ivana Varekova removed these directory 
ownings some time ago (unfortunately).
Comment 9 Robert Scheck 2007-04-28 10:55:33 EDT
Bill/Phil, ping?
Comment 10 Bill Nottingham 2007-05-01 00:38:26 EDT
lang-specific man stuff should be in man-pages-<lang> or in the package that
provides them - having filesystem own directories for all possible langauges
that man pages could be in is overkill. (At least for translations, a decent
plurality of those locales are actually used.)

If manXp is the perl stuff, perhaps it should be owned by the man perl package.
Comment 11 Bug Zapper 2008-04-03 14:48:17 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 12 Robert Scheck 2008-04-03 16:40:58 EDT
Hum? Since when is Rawhide no longer maintained? The problem still exists in 
Rawhide.
Comment 13 Bug Zapper 2008-05-13 22:30:56 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Robert Scheck 2008-07-27 10:49:53 EDT
This still applies on Rawhide.
Comment 15 Bug Zapper 2008-11-25 20:51:55 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-06-09 05:11:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 17 Dennis Gregorovic 2009-06-26 09:42:01 EDT
(In reply to comment #10)
> lang-specific man stuff should be in man-pages-<lang> or in the package that
> provides them - having filesystem own directories for all possible langauges
> that man pages could be in is overkill. (At least for translations, a decent
> plurality of those locales are actually used.)
> 
> If manXp is the perl stuff, perhaps it should be owned by the man perl package.  

Should this bug be moved to the man component then?  Here's a recent of unowned directories:

/usr/share/man/ca
/usr/share/man/ca/man1
/usr/share/man/ca/man6
/usr/share/man/ca/man7
/usr/share/man/ca/man8
/usr/share/man/da/man6
/usr/share/man/eo
/usr/share/man/eo/man1
/usr/share/man/es/man2
/usr/share/man/es/man3
/usr/share/man/es/man4
/usr/share/man/es/man6
/usr/share/man/es/man7
/usr/share/man/et
/usr/share/man/et/man1
/usr/share/man/et/man6
/usr/share/man/et/man7
/usr/share/man/et/man8
/usr/share/man/gl
/usr/share/man/gl/man1
/usr/share/man/gl/man6
/usr/share/man/gl/man7
/usr/share/man/gl/man8
/usr/share/man/hu
/usr/share/man/hu/man1
/usr/share/man/hu/man4
/usr/share/man/hu/man8
/usr/share/man/id
/usr/share/man/id/man8
/usr/share/man/nb
/usr/share/man/nb/man1
/usr/share/man/nl/man6
/usr/share/man/nn
/usr/share/man/nn/man1
/usr/share/man/pt_BR
/usr/share/man/pt_BR/man1
/usr/share/man/pt_BR/man5
/usr/share/man/pt_BR/man6
/usr/share/man/pt_BR/man7
/usr/share/man/pt_BR/man8
/usr/share/man/pt/man6
/usr/share/man/pt/man7
/usr/share/man/sk
/usr/share/man/sk/man8
/usr/share/man/sr
/usr/share/man/sr/man1
/usr/share/man/sv
/usr/share/man/sv/man1
/usr/share/man/sv/man3
/usr/share/man/sv/man5
/usr/share/man/sv/man6
/usr/share/man/sv/man7
/usr/share/man/sv/man8
/usr/share/man/tr
/usr/share/man/tr/man1
/usr/share/man/tr/man5
/usr/share/man/tr/man8
/usr/share/man/zh_CN
/usr/share/man/zh_CN/man1
/usr/share/man/zh_CN/man8
/usr/share/man/zh_TW
/usr/share/man/zh_TW/man1
/usr/share/man/zh_TW/man8
Comment 18 Ondrej Vasik 2009-07-07 11:02:13 EDT
Good to have up2date list. As written in Comment #10, lang related manpages dir should be owned by those packages. Maybe that bugzilla could be used as tracker bug and separate bugzillas against those man-pages-lang components could be created. Anyway, reassigning to man-pages, they could decide how to handle this - I don't think it should be done by filesystem package.
Comment 19 Ivana Varekova 2009-07-08 06:58:15 EDT
Hello, 
man-pages package does not have any file from these subdirectories - so it has no sense to reassign the bug to this package. 

Dennis: please could you look which packages owns a file in unowned directories and create a bug directly on these component?
Comment 20 Dennis Gregorovic 2009-07-08 15:58:22 EDT
(In reply to comment #19)
> Dennis: please could you look which packages owns a file in unowned directories
> and create a bug directly on these component?  

Done.
Comment 21 Robert Scheck 2009-07-08 16:38:24 EDT
I'm not really sure whether jwhois really should own /usr/share/man/sv/man1
and I'm not sure, whether this is conform to the packaging guidelines as well.
Comment 22 Ondrej Vasik 2009-07-09 02:06:27 EDT
Robert: Packaging guideline is to: "Own all directories you create but none of the directories of packages you depend on. Additionally no package in Fedora should ever share ownership with any of the files owned by the filesystem or man package."
As filesystem and man-pages are not going to own those dirs, packages which do create those directories(and use them for their files) should own them.

Dennis: Thanks!
Comment 23 Ivana Varekova 2009-07-09 02:28:28 EDT
Thanks Dennis.
Comment 24 Axel Thimm 2009-07-27 15:31:29 EDT
(In reply to comment #21)
> I'm not really sure whether jwhois really should own /usr/share/man/sv/man1

I agree, the same would need to be owned by fakeroot, dcraw and even shadow-utils as well.

> and I'm not sure, whether this is conform to the packaging guidelines as well.  

(In reply to comment #22)
> Robert: Packaging guideline is to: "Own all directories you create but none of
> the directories of packages you depend on. Additionally no package in Fedora
> should ever share ownership with any of the files owned by the filesystem or
> man package."
> As filesystem and man-pages are not going to own those dirs, packages which do
> create those directories(and use them for their files) should own them.

So a packager that encounters a man path that is unowned by man/filesystem asks repoquery as to --whatprovides this path and ends up with jwhois, fakeroot or some other package. If he reads the guidelines to the letter instead of coowning this man path he might as well just depend on one of these packages ...

What I'm trying to say is that the guidelines are there to explain how to package up things and not how to create strange scenarios. The next packager with /usr/share/man/sv/man1 will also not know what to do and will probably do the wrong thing (whatever the right thing is).

I think either a locale is broken, so it is the packager's responsibility to remove or adjust the locale of the man page, or it needs to be owned by man.

Ownership of directories means that the contents are related to the owner, and the man pages of say

dcraw-8.91-1.fc11.x86_64
fakeroot-1.12.2-21.fc11.x86_64
jwhois-4.0-13.fc11.x86_64
shadow-utils-4.1.2-13.fc11.x86_64

that suddenly are required to own all subdirs from /usr/share/man/sv/ are completely unrelated to each other.

Ivana, please reconsider, I understand that you feel like this "pollutes" your package with folders you don't directly need, but the other solution is to pollute many more packages with he same, and if feels much uncleaner to do so in not man related packages. And the above example shows that the same stray ownership is being multiplied by four (dcraw, fakeroot, jwhois and shadow-utils now need to own the dirs of the subtree below /usr/share/man/sv/).
Comment 25 Axel Thimm 2009-07-27 15:33:03 EDT
*** Bug 510359 has been marked as a duplicate of this bug. ***
Comment 26 Axel Thimm 2009-07-27 15:57:12 EDT
(In reply to bug #510360 comment #1)
> Fixed, until there are stock Hungarian man pages in which case it'll become a
> bug to own the dir  

I hadn't thought of that, which makes it even more important to stick to one place for the directory ownership. Should one of the 19 locale above, be it Hungarian, Portuguese, Danish or Chinese etc. be supported by a future man or man-pages package it will suddenly make the client packages' current fix a bug to remove.
Comment 27 Ondrej Vasik 2009-08-03 09:09:34 EDT
Ivana is reluctant to add it to man package - and she has some good arguments for this. After reading fedora-packaging thread https://www.redhat.com/archives/fedora-packaging/2009-July/msg00133.html , I was convinced by the discussions and I'm ok with having /usr/share/man/<locales> ghosted and owned by filesystem package. Done in filesystem-2.4.26-1.fc12. As sideeffect - now there will be many man directories owned by filesystem AND some additional package(s) - which turns to be a bug now. I'm a bit reluctant to add ghosted man subsections to filesystem (as it means ~10k additional entries in filesystem rpm -ql).
Comment 28 Ondrej Vasik 2009-08-05 06:39:12 EDT
Ignore #27, I added those ghosted man subsections to locale dirs as well in filesystem-2.4.28-1.fc12, rpm -ql is already almost useless without grep due to locales/LC_MESSAGES, so no significant change...
The same set of locales as for /usr/share/locale/<locale> is used and the same set of man subsections as in /usr/share/man is used. So likely many packages will no need removal of ownership for %dir /usr/share/man/<locale> and %dir /usr/share/man/<locale>/man{1,2,3,4,5,6,7,8,9,n,1x,2x,3x,4x,5x,6x,7x,8x,9x,0p,1p,3p}
.
Comment 29 Ondrej Vasik 2009-10-20 04:54:56 EDT
As it was originally RAWHIDE bugzilla and problem is fixed in rawhide, closing RAWHIDE.

Note: as all /usr/share/man/<locale> and /usr/share/man/<locale>/man{1,2,3,4,5,6,7,8,9,n,1x,2x,3x,4x,5x,6x,7x,8x,9x,0p,1p,3p} are now owned by filesystem, maybe some tracking bugzilla and separate bug reports for components owning those dirs has to be filled.

Note You need to log in before you can comment on or make changes to this bug.