Phil, somebody needs to own these dirs.  Do you have an opinion on whether it
should be here (man) or in filesystem?

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

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. 

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

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.

Ping?

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).

Bill/Phil, ping?

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.

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.

Hum? Since when is Rawhide no longer maintained? The problem still exists in 
Rawhide.

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

This still applies on Rawhide.

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

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

(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

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.

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?

(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.

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.

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!

Thanks Dennis.

(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/).

*** Bug 510359 has been marked as a duplicate of this bug. ***

(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.

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).

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}
.

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.