FWIW. gtk-doc should not be required to build the packages either... the
gtk-doc documentation should be distributed as HTML in the tarballs.

You should file individual bugs for the packages.  This is something for the package maintainers to fix.

Seriously? You want me to file 94 bug reports? Isn't this something that the Fedora distribution as whole is interested in. I'm guessing you probably have tools to do that automatically, I don't.

Actually, there is this concept of "tracking bug" like bug #333741. This one should be that way.

Tracking bugs are used to track other individually filed bugs.  Not as a pile on.  Pile on bugs are completely unmaintainable.

The tools we have to file bugs are the same tools you have.  There is a command line took, /usr/bin/bugzilla which comes from the 'python-bugzilla' package.  It can be used to file bugs repeatedly from the command line, as part of a script.  You'd want to find the source rpm name of each of the above packages, reduce them to a unique set, then loop over those filing the bug.  I do believe you can even make all of them "block" this bug, which would turn it into an actual tracker bug.

(In reply to comment #5)
> Tracking bugs are used to track other individually filed bugs.  Not as a pile
> on.  Pile on bugs are completely unmaintainable.

I guess so.

> The tools we have to file bugs are the same tools you have.  There is a command
> line took, /usr/bin/bugzilla which comes from the 'python-bugzilla' package. 
> It can be used to file bugs repeatedly from the command line, as part of a
> script.  You'd want to find the source rpm name of each of the above packages,
> reduce them to a unique set, then loop over those filing the bug.  I do believe
> you can even make all of them "block" this bug, which would turn it into an
> actual tracker bug.    

No, it's not possible to mark them as block automatically... and I actually think that would not be best.

Also, I think it would have been much easier (and safer) if you did that instead, but anyway, here it goes.

Have you taken directory ownership into account? /usr/share/gtk-doc/ is owned by gtk-doc, so whatever puts files in there should depend on gtk-doc. If not, we have unowned directories and need to let the filesystem package own this dir.

This should be brought up with the packaging committee IMO.  The reason libgpod-doc requires gtk-doc is because it provides the %{_datadir}/gtk-doc dir.  Of course it is perfectly valid for all the packages which place files there to own this directory, but it seems like something that ought to be discussed before mass filing of bugs and asking folks to make changes.

It would seem reasonable for some other package to own this dir, perhaps gtk-doc-filesystem or whatever.  Then packages dropping files here could require that.

(In reply to comment #8)
> This should be brought up with the packaging committee IMO.  The reason
> libgpod-doc requires gtk-doc is because it provides the %{_datadir}/gtk-doc
> dir.

I believe that most of these packages are requiring gtk-doc for this same reason.

So if we shouldn't require gtk-doc, what should we require for directory ownership of %{_datadir}/gtk-doc ?

(In reply to comment #7)
> Have you taken directory ownership into account? /usr/share/gtk-doc/ is owned
> by gtk-doc, so whatever puts files in there should depend on gtk-doc. If not,
> we have unowned directories and need to let the filesystem package own this
> dir.    

In my machine /usr/share/gtk-doc has root.root ownership, so I don't know what you are talking about.

And: $ rpm -q --whatprovides /usr/share/gtk-doc
gnome-python2-gnomevfs-2.28.1-1.fc13.i686

$ repoquery --whatprovides /usr/share/gtk-doc
gtk-doc-0:1.14-1.fc13.noarch
gdome2-devel-0:0.8.1-9.fc12.i686
gnome-python2-gnomevfs-0:2.28.1-1.fc13.i686

Besides... have you taked a look at the insane amount of dependencies gtk-doc has? I certainly think that requiring the user to install such an amount of useless crap (in the typical use-cases) just to have some .html files is overkill.

If /usr/share/gtk-doc requires certain permissions (which I doubt), then a separate gtk-doc-filesystem (or something like that) could be provided.

(In reply to comment #8)
> This should be brought up with the packaging committee IMO.  The reason
> libgpod-doc requires gtk-doc is because it provides the %{_datadir}/gtk-doc
> dir.  Of course it is perfectly valid for all the packages which place files
> there to own this directory, but it seems like something that ought to be
> discussed before mass filing of bugs and asking folks to make changes.

I was feeling that was the case, that's why I filed the bug to 'distribution', but Jesse Keating kind of forced me to do it this way.

> It would seem reasonable for some other package to own this dir, perhaps
> gtk-doc-filesystem or whatever.  Then packages dropping files here could
> require that.    

Exactly.

(In reply to comment #10)
> In my machine /usr/share/gtk-doc has root.root ownership, so I don't know what
> you are talking about.

It is not about user/group ownership but about the ownership of the directory in the rpmdb. It must be owned, otherwise an empty, unowned dir remains when the last package that dropped files in there is removed.

> And: $ rpm -q --whatprovides /usr/share/gtk-doc
> gnome-python2-gnomevfs-2.28.1-1.fc13.i686

This is actually a packaging bug.

> $ repoquery --whatprovides /usr/share/gtk-doc
> gtk-doc-0:1.14-1.fc13.noarch
> gdome2-devel-0:0.8.1-9.fc12.i686
> gnome-python2-gnomevfs-0:2.28.1-1.fc13.i686

gtk-doc is the only package that should own %{datadir}/gtk-doc and the other packages need to depend on it. Please read
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

> Besides... have you taked a look at the insane amount of dependencies gtk-doc
> has? I certainly think that requiring the user to install such an amount of
> useless crap (in the typical use-cases) just to have some .html files is
> overkill.

Users who have *-devel packages installed are usually developers and they need these tools to build the documentation. In fact, they already will have most dependencies of gtkdoc installed anyway.

> If /usr/share/gtk-doc requires certain permissions (which I doubt), then a
> separate gtk-doc-filesystem (or something like that) could be provided.    

Indeed, this would be an option, but until we have this package (or anything else owning the directory), the dependencies are correct.

According to the guidelines, this is not a bug unless one of the two cases is satisfied:

- There is a specific guideline that tells us to own the directory /usr/share/gtk-doc instead of requiring the gtk-doc package.
- There is some sort of a gtk-doc-filesystem package that owns the directory /usr/share/gtk-doc

None of the above two are true for the time being. I think you were a bit too early to mass-file bugs.

What is the problem you are trying to solve here ? These are all devel packages, cd-size is not a concern. What problem do these dependencies cause for you ?
Excessive modularity is not a feature...

(In reply to comment #14)
> What is the problem you are trying to solve here ? These are all devel
> packages, cd-size is not a concern. What problem do these dependencies cause
> for you ?

The problem is that packages are installed which are not needed. If install gstreamer-devel-docs, I expect no dependencies; the documentation is installed, and that's that. Instead, I need to install 30M of packages that I will never use.

If everybody keeps depending on packages that are not needed then installation sizes would quickly blow up (maybe it's already the case).

> Excessive modularity is not a feature...    

Excuse me, but we agree that:
right: depend on what you need
wrong: depend on what you don't need

Yeah?

Perhaps doing the right thing is not a feature, but it's still the right thing to do.

You can argue that this is low priority, but it it's still the right thing to do.

(In reply to comment #13)
> - There is some sort of a gtk-doc-filesystem package that owns the directory
> /usr/share/gtk-doc

I can create a new bug report for that, but I think Todd Zullinger's idea of bringing this to the packaging committee (is such thing is possible) is the right way to go.

> None of the above two are true for the time being. I think you were a bit too
> early to mass-file bugs.    

Not my idea, but now that the damage has been done, I believe we have two options:

 a) Close all the bugs and reopen them later if needed (based on this bug's resolution)
 b) Keep the bugs open and close them if the tracking bug is closed

I would rather go for b) since it would create less noise.

(In reply to comment #13)
> - There is a specific guideline that tells us to own the directory
> /usr/share/gtk-doc instead of requiring the gtk-doc package.

(In reply to comment #12)
> gtk-doc is the only package that should own %{datadir}/gtk-doc and the other
> packages need to depend on it.

In fact, it's mentioned in the guideline:

Multiple packages own files in a common directory but none of them needs to require the others

Rule of Thumb
When determining whether this exception applies, packagers and reviewers should ask this question: Do the files in this common directory enhance or add functionality to another package, where that other package is not necessary to be present for the primary functionality of this package?

So, is the other package (gtk-doc) necessary to be present for the primary functionality of the package?

No.

(In fact the answer is even simpler because the -devel packaged don't even enhance the functionality of gtk-doc; they are completely independent)

Therefore, all the -devel packages need to own the /usr/share/gtk-doc directory.

Please first discuss this type of issue in fedora-packaging mailing
list before filing a pile of bugs which will confuse many maintainers.

This type of confusion occurred before, e.g. for about filtering error
messages about install-info, and many maintainers complained about
such bug filing _before_ enough discussion was done. Please discuss
on fedora-packaging mailing list _first_

(In reply to comment #12)
> (In reply to comment #10)
 
> > And: $ rpm -q --whatprovides /usr/share/gtk-doc
> > gnome-python2-gnomevfs-2.28.1-1.fc13.i686
> 
> This is actually a packaging bug.
> 
> > $ repoquery --whatprovides /usr/share/gtk-doc
> > gtk-doc-0:1.14-1.fc13.noarch
> > gdome2-devel-0:0.8.1-9.fc12.i686
> > gnome-python2-gnomevfs-0:2.28.1-1.fc13.i686
> 
> gtk-doc is the only package that should own %{datadir}/gtk-doc and the other
> packages need to depend on it. Please read
> https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership

I have fixed this in Rawhide now.  Not doing a build however.  When it is updated to pull in the latest upstream, that can happen.

I suggest to add gnome-filesystem instead of several scattered filesystem packages which now already existed in desktop spin to own common directires like /usr/share/gtk-doc in gnome desktop.

Simply because gtk-doc has the ownership of a directory to force all package to requires the gtk-doc is unacceptable. gtk-doc is a doxygen-like tool, it cannot be used to open any html files.

The same case will be evoked if we consider Vala API files(/usr/share/vala/vapi), should all -devel subpackages which contain .vapi files must require on vala? Actually, most packages which depend on those -devel subpackages is written by C/C++, thus those vala API files is useless under many circumstance.

Again please discuss this first on fedora-packaging list.

Considering that this affects such a large number of packages, it probably isn't practical to target this 100% for F-13, so I'm going to take the liberty to rebase this against rawhide.

I'll start a thread on -packaging list on how best to move forward here.

(In reply to comment #22)
> I'll start a thread on -packaging list on how best to move forward here.

I just tried to do that:
Your message to packaging awaits moderator approval

You need to subscribe to the mailing list. How else would you get the replies to your mail?

(In reply to comment #24)
> You need to subscribe to the mailing list. How else would you get the replies
> to your mail?    

CC, just like in many other mailing lists (e.g. LKML).

I don't really see any consensus on the packaging list off hand. 

It would be nice if FPC could talk about this at their next meeting and update this bug once some way forward is decided.

I suggest to once close this as NOTABUG.

It looks like there is a draft saying all the packages should just own the dir: 

https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function

I'm going to wait for the FPC to look at that before closing any of my bugs, I suggest others do the same.

(In reply to comment #28)
> I'm going to wait for the FPC to look at that before closing any of my bugs, I
> suggest others do the same.    

Did this happen?

Not so far as I can tell. ;( 

I posted to the packaging list to ask when the next meeting will be. 
http://lists.fedoraproject.org/pipermail/packaging/2010-August/007306.html

FPC did meet last week. See: 

https://fedorahosted.org/fpc/ticket/5

In which they approved https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership

Which by my reading means that all packages which place files in /usr/share/gtk-doc/ should go ahead and own that dir. (root/root, mode 755).

(In reply to comment #31)
> FPC did meet last week. See: 
> 
> https://fedorahosted.org/fpc/ticket/5
> 
> In which they approved
> https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership
> 
> Which by my reading means that all packages which place files in
> /usr/share/gtk-doc/ should go ahead and own that dir. (root/root, mode 755).

Excellent :)

I've reopened the closed NOTABUG dependent bugs.

(In reply to comment #31)
> FPC did meet last week. See: 
> 
> https://fedorahosted.org/fpc/ticket/5
> 
> In which they approved
> https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership
> 
> Which by my reading means that all packages which place files in
> /usr/share/gtk-doc/ should go ahead and own that dir. (root/root, mode 755).

Don't we need to open a new bug for this then? At the time this bug was filed, it was NOTABUG.

(In reply to comment #33)
> Don't we need to open a new bug for this then? At the time this bug was filed,
> it was NOTABUG.

This bug has never been been marked as NOTABUG.

And I disagree that it was ever NOTABUG, as I say in comment #17, the guideline already had this issue explained; the example is with /etc/bash_completion.d. The change was to clarify the situation, specifically with regards to gtk-doc. As you can see in the draft, now bash completion is listed as "another example".

The dependent bugs that were closed as NOTABUG (minority) did it wrongly (prematurely) IMO. I didn't reopen all of them to prevent noise.

If your suggestion is to mark all 94 bugs as NOTABUG, and open another 94 bugs with exactly the same content, I think that's wrong, and even this was NOTABUG at some point: unnecessary and way too much noise.

(In reply to comment #34)
> 
> And I disagree that it was ever NOTABUG, as I say in comment #17, the guideline
> already had this issue explained; the example is with /etc/bash_completion.d.
> The change was to clarify the situation, specifically with regards to gtk-doc.
> As you can see in the draft, now bash completion is listed as "another
> example".
> 

Ah, sorry. This is not a change in the guideline, but rather it is a clarification in the interpretation of a guideline. Thus it was not NOTABUG.

> If your suggestion is to mark all 94 bugs as NOTABUG, and open another 94 bugs
> with exactly the same content, I think that's wrong, and even this was NOTABUG
> at some point: unnecessary and way too much noise.

I disagree here as this would violate causality. Closed timelike curves don't exist in the world we know.


Anyhow, I see a number of bugs closed RAWHIDE. However the bugs were filed against F-13. Are we allowed to close a bug RAWHIDE that is filed to a stable version of Fedora?

I would object to this being fixed anywhere except rawhide. (And then it could go to stable releases with other changes that are worthy of an update). It seems to me a change not worthly of a stable updates release by itself. 

I don't think there's much point to re-filing everything.

(In reply to comment #34)
> (In reply to comment #33)
> > Don't we need to open a new bug for this then? At the time this bug was filed,
> > it was NOTABUG.
> 
> This bug has never been been marked as NOTABUG.
> 
Would you mind to generate a new package list that depend on gtk-doc? Some new packages which was approved after this tracking bug also add gtk-doc as dependency.

So is the final consensus on this that each devek/doc package should own the gtk-doc directory? Have the packaging guidelines be updated to reflect this?

Yes, see https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership

(This bug is a long read... was the idea of a filesystem package
to own the dir discussed/rejected?)

(In reply to comment #40)
> (This bug is a long read... was the idea of a filesystem package
> to own the dir discussed/rejected?)

It was accepted. Packages should own the directory (root:root).

cairomm-1.9.8-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cairomm-1.9.8-1.fc15

cairomm-1.9.8-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/cairomm-1.9.8-1.fc14

Rick, the bug you fix with your updates is bug 604339 and not this one. Please edit your updates.

cairomm-1.9.8-1.fc15, gtkmm30-2.99.3-3.fc15 has been pushed to the Fedora 15 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cairomm gtkmm30'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gtkmm30-2.99.3-3.fc15,cairomm-1.9.8-1.fc15

All right, I have updated the dependent bugs for F15.

anjuta-devel-1:3.0.0.0-2.fc15.i686
anjuta-devel-1:3.0.0.0-2.fc15.x86_64
bamf-devel-0:0.2.74-2.fc15.i686
bamf-devel-0:0.2.74-2.fc15.x86_64
clipsmm-doc-0:0.1.0-4.fc14.1.noarch
conexus-doc-0:0.9.1-3.fc14.1.noarch
ctpl-doc-0:0.3.2-2.fc15.noarch
dbus-cxx-doc-0:0.7.0-2.fc14.1.noarch
eekboard-devel-0:0.90.7-1.fc15.i686
eekboard-devel-0:0.90.7-1.fc15.x86_64
fprintd-devel-0:0.2.0-3.fc15.noarch
gegl-devel-0:0.1.6-2.fc15.i686
gegl-devel-0:0.1.6-2.fc15.x86_64
glade3-libgladeui-devel-1:3.10.0-2.fc15.i686
glade3-libgladeui-devel-1:3.10.0-2.fc15.x86_64
gnome-desktop3-devel-0:3.0.1-2.fc15.i686
gnome-desktop3-devel-0:3.0.1-2.fc15.x86_64
gstreamer-devel-docs-0:0.10.32-4.fc15.noarch
gstreamer-devel-docs-0:0.10.34-1.fc15.noarch
gstreamer-plugins-base-devel-docs-0:0.10.32-2.fc15.noarch
gstreamer-plugins-base-devel-docs-0:0.10.33-1.fc15.noarch
gstreamer-plugins-good-devel-docs-0:0.10.27-4.fc15.noarch
gstreamer-plugins-good-devel-docs-0:0.10.29-1.fc15.noarch
gtksourcecompletion-doc-0:0.7.0-3.fc15.x86_64
gypsy-docs-0:0.8-2.fc15.noarch
json-glib-devel-0:0.12.0-2.fc15.i686
json-glib-devel-0:0.12.0-2.fc15.x86_64
libbeagle-devel-0:0.3.9-7.fc15.i686
libbeagle-devel-0:0.3.9-7.fc15.x86_64
libchamplain-devel-0:0.10.0-2.fc15.i686
libchamplain-devel-0:0.10.0-2.fc15.x86_64
libchamplain-gtk-devel-0:0.10.0-2.fc15.i686
libchamplain-gtk-devel-0:0.10.0-2.fc15.x86_64
libgdata-devel-0:0.8.0-2.fc15.i686
libgdata-devel-0:0.8.0-2.fc15.x86_64
libgdata-devel-0:0.8.1-1.fc15.i686
libgdata-devel-0:0.8.1-1.fc15.x86_64
libgdl-devel-1:3.0.0-1.fc15.i686
libgdl-devel-1:3.0.0-1.fc15.x86_64
libgnomecanvas-devel-0:2.30.3-2.fc15.i686
libgnomecanvas-devel-0:2.30.3-2.fc15.x86_64
libgnomeprint22-devel-0:2.18.8-2.fc15.i686
libgnomeprint22-devel-0:2.18.8-2.fc15.x86_64
libgtop2-devel-0:2.28.3-1.fc15.i686
libgtop2-devel-0:2.28.3-1.fc15.x86_64
libgweather-devel-0:3.0.0-1.fc15.i686
libgweather-devel-0:3.0.0-1.fc15.x86_64
libhildon-doc-0:2.0.6-5.fc13.x86_64
libiptcdata-devel-0:1.0.4-4.fc15.i686
libiptcdata-devel-0:1.0.4-4.fc15.x86_64
libmirage-devel-0:1.1.0-5.fc12.i686
libmirage-devel-0:1.1.0-5.fc12.x86_64
liboil-devel-0:0.3.16-5.fc15.i686
liboil-devel-0:0.3.16-5.fc15.x86_64
libpeas-devel-0:1.0.0-1.fc15.i686
libpeas-devel-0:1.0.0-1.fc15.x86_64
libvtemm-docs-0:0.23.1-2.fc15.x86_64
papyrus-doc-0:0.13.3-2.fc14.1.noarch
poppler-devel-0:0.16.5-1.fc15.i686
poppler-devel-0:0.16.5-1.fc15.x86_64
seahorse-devel-0:3.0.1-1.fc15.i686
seahorse-devel-0:3.0.1-1.fc15.x86_64
seed-doc-0:3.0.0-1.fc15.noarch
streamtuner-0:2.0.8-8.fc15.noarch
unique-devel-0:1.1.6-1.fc13.i686
unique-devel-0:1.1.6-1.fc13.x86_64
uprof-devel-0:0.3-0.2.20110115gita6832f7a.fc15.i686
uprof-devel-0:0.3-0.2.20110115gita6832f7a.fc15.x86_64
xfce4-dev-tools-0:4.8.0-2.fc15.noarch

(In reply to comment #46)
> All right, I have updated the dependent bugs for F15.

This is a packaging bug that does not jusitfy an update in a stable release. Please refer to https://fedoraproject.org/wiki/Updates_Policy for more information.

This being said you should have updated this list during the F15 development cycle. After the release further investigation should happen based on rawhide and target F16.

Updated for Fedora 16.