gtk-doc is only needed to *build* the documentation... once the documentation is built, the result are HTML files that can be copied to '/usr/share/gtk-doc/'. For copying the HTML files you only need the 'install' command, not gtk-doc. And of course, in order to view HTML files you don't need gtk-doc either. Here's the list: ORBit2-devel-0:2.14.18-1.fc13.i686 anjuta-devel-1:2.30.0.0-2.fc13.i686 cairomm-doc-0:1.8.4-1.fc13.noarch cheese-libs-devel-0:2.30.1-1.fc13.i686 clipsmm-doc-0:0.1.0-2.fc12.noarch clutter-gst-devel-0:1.0.0-1.fc13.i686 clutter-imcontext-devel-0:0.1.6-1.fc13.i686 conexus-doc-0:0.9.1-1.fc13.noarch dbus-cxx-doc-0:0.7.0-1.fc13.noarch eggdbus-devel-0:0.6-2.fc13.i686 eog-devel-0:2.30.1-1.fc13.i686 epiphany-devel-0:2.30.2-1.fc13.i686 ethos-docs-0:0.2.2-4.fc13.noarch exo-devel-0:0.3.106-2.fc13.i686 exo-devel-0:0.3.106-3.fc13.i686 fprintd-devel-0:0.1-16.git04fd09cfa.fc13.noarch garcon-devel-0:0.1.0-2.fc13.i686 gedit-devel-1:2.30.2-1.fc13.i686 geoclue-doc-0:0.12.0-1.fc13.noarch gimp-devel-2:2.6.8-6.fc13.i686 glade3-libgladeui-devel-0:3.6.7-2.fc12.i686 gnome-bluetooth-libs-devel-0:2.30.0-1.fc13.i686 gnome-desktop-devel-0:2.30.0-3.fc13.i686 gnome-keyring-devel-0:2.30.1-2.fc13.i686 gnome-panel-devel-0:2.30.0-1.fc13.i686 gok-devel-0:2.30.0-1.fc13.i686 gssdp-docs-0:0.7.2-1.fc13.noarch gstreamer-devel-docs-0:0.10.29-1.fc13.noarch gstreamer-plugins-base-devel-docs-0:0.10.29-1.fc13.noarch gstreamer-plugins-good-devel-docs-0:0.10.23-1.fc13.noarch gtk2-devel-docs-0:2.20.1-1.fc13.i686 gtkimageview-devel-0:1.6.3-2.fc12.i686 gtksourcecompletion-doc-0:0.7.0-2.fc12.i686 gupnp-av-docs-0:0.5.5-1.fc13.noarch gupnp-docs-0:0.13.3-4.fc13.noarch gupnp-ui-docs-0:0.1.1-7.fc13.noarch gypsy-docs-0:0.7-1.fc12.noarch ibus-devel-docs-0:1.3.3-1.fc13.i686 ibus-devel-docs-0:1.3.5-2.fc13.i686 jana-devel-0:0.4.5-0.3.20090622gitb416a41.fc12.i686 json-glib-devel-0:0.10.4-1.fc13.i686 libbeagle-devel-0:0.3.9-5.fc12.i686 libcanberra-devel-0:0.23-1.fc13.i686 libcanberra-devel-0:0.24-1.fc13.i686 libccss-devel-0:0.3.1-3.fc12.i686 libchamplain-devel-0:0.4.5-1.fc13.i686 libchamplain-gtk-devel-0:0.4.5-1.fc13.i686 libgdata-devel-0:0.6.4-1.fc13.i686 libgdl-devel-0:2.30.0-1.fc13.i686 libgnome-devel-0:2.30.0-1.fc13.i686 libgnome-keyring-devel-0:2.30.0-2.fc13.i686 libgnomecanvas-devel-0:2.30.1-1.fc13.i686 libgnomeprint22-devel-0:2.18.7-1.fc13.i686 libgpod-doc-0:0.7.91-2.fc13.noarch libgtop2-devel-0:2.28.1-2.fc13.i686 libgweather-devel-0:2.30.0-1.fc13.i686 libhildon-doc-0:2.0.6-5.fc13.i686 libiptcdata-devel-0:1.0.4-2.fc12.i686 libmirage-devel-0:1.1.0-5.fc12.i686 libmx-docs-0:0.99.7-1.fc13.noarch libmx-docs-0:1.0.1-1.fc13.noarch liboil-devel-0:0.3.16-4.fc12.i686 libsoup-devel-0:2.30.1-1.fc13.i686 libvtemm-docs-0:0.23.1-1.fc13.i686 libwnck-devel-0:2.30.0-1.fc13.i686 libxfce4ui-devel-0:4.7.1-2.fc13.i686 libxfce4ui-devel-0:4.7.2-1.fc13.i686 libxfce4util-devel-0:4.6.1-2.fc12.i686 libxfcegui4-devel-0:4.6.3-1.fc13.i686 libxklavier-devel-0:5.0-1.fc13.i686 mutter-devel-0:2.29.1-1.fc13.i686 mutter-mbl-devel-0:2.28.1_0.12-1.fc13.i686 nautilus-sendto-devel-0:2.28.4-1.fc13.i686 pangomm-devel-0:2.26.0-2.fc13.i686 papyrus-doc-0:0.13.2-1.fc13.noarch papyrus-doc-0:0.13.3-1.fc13.noarch parole-devel-0:0.2.0.2-2.fc13.i686 polkit-docs-0:0.96-1.fc13.i686 polkit-gnome-docs-0:0.96-1.fc13.i686 poppler-devel-0:0.12.4-2.fc13.i686 rasqal-devel-0:0.9.17-2.fc13.i686 redland-devel-0:1.0.10-4.fc13.i686 seahorse-devel-0:2.30.0-1.fc13.i686 seahorse-devel-0:2.30.1-1.fc13.i686 tomoe-devel-0:0.6.0-15.fc12.i686 twitter-glib-devel-0:0.9.8-5.fc13.i686 udisks-devel-0:1.0.1-1.fc13.i686 unique-devel-0:1.1.6-1.fc13.i686 upower-devel-0:0.9.2-1.fc13.i686 upower-devel-0:0.9.4-1.fc13.i686 vips-devel-0:7.20.7-1.fc13.i686 xfce4-dev-tools-0:4.7.2-1.fc12.noarch xfconf-devel-0:4.6.1-5.fc13.i686 xfprint-devel-0:4.6.0-4.fc13.i686
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.