Bug 604169 - Tracking bug for packages that depend on gtk-doc unnecessarily
Tracking bug for packages that depend on gtk-doc unnecessarily
Status: ON_QA
Product: Fedora
Classification: Fedora
Component: gtk-doc (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
: EasyFix, Tracking
Depends On: 604338 604339 604340 604341 604342 604343 604344 604345 604346 604347 604348 604349 604350 604351 604352 604353 604354 604355 604356 604357 604358 604359 604360 604361 604362 604363 604365 604366 604367 604368 604369 604370 604371 604372 604374 604375 604376 604377 604378 604379 604380 604381 604382 604383 604384 604385 604386 604387 604388 604389 604390 604391 604392 604393 604394 604395 604396 604397 604398 604399 604400 604401 604402 604403 604404 604405 604406 604407 604408 604409 604410 604411 604412 604413 604414 604415 604416 604417 604418 604419 604420 604421 604422 604423 604424 707545 707547 707551 707554 707557 707562 707564 707566 707567 707571 707572 707573 754495 754500 754501 754510
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-15 10:38 EDT by Felipe Contreras
Modified: 2013-04-01 11:30 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-15 12:10:58 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 Felipe Contreras 2010-06-15 10:38:11 EDT
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
Comment 1 Felipe Contreras 2010-06-15 10:44:37 EDT
FWIW. gtk-doc should not be required to build the packages either... the
gtk-doc documentation should be distributed as HTML in the tarballs.
Comment 2 Jesse Keating 2010-06-15 12:10:58 EDT
You should file individual bugs for the packages.  This is something for the package maintainers to fix.
Comment 3 Felipe Contreras 2010-06-15 13:25:18 EDT
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.
Comment 4 Felipe Contreras 2010-06-15 13:27:20 EDT
Actually, there is this concept of "tracking bug" like bug #333741. This one should be that way.
Comment 5 Jesse Keating 2010-06-15 15:05:01 EDT
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.
Comment 6 Felipe Contreras 2010-06-15 17:06:31 EDT
(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.
Comment 7 Christoph Wickert 2010-06-15 17:15:13 EDT
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.
Comment 8 Todd Zullinger 2010-06-15 17:22:08 EDT
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.
Comment 9 Orcan Ogetbil 2010-06-15 17:29:12 EDT
(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 ?
Comment 10 Felipe Contreras 2010-06-15 17:42:48 EDT
(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.
Comment 11 Felipe Contreras 2010-06-15 17:47:27 EDT
(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.
Comment 12 Christoph Wickert 2010-06-15 17:56:21 EDT
(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.
Comment 13 Orcan Ogetbil 2010-06-15 17:58:16 EDT
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.
Comment 14 Matthias Clasen 2010-06-15 18:09:12 EDT
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...
Comment 15 Felipe Contreras 2010-06-15 18:37:58 EDT
(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.
Comment 16 Felipe Contreras 2010-06-15 18:44:21 EDT
(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.
Comment 17 Felipe Contreras 2010-06-15 19:53:26 EDT
(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.
Comment 18 Mamoru TASAKA 2010-06-16 01:18:40 EDT
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_
Comment 19 Rahul Sundaram 2010-06-16 04:30:02 EDT
(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.
Comment 20 Chen Lei 2010-06-16 06:19:50 EDT
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.
Comment 21 Mamoru TASAKA 2010-06-16 07:43:49 EDT
Again please discuss this first on fedora-packaging list.
Comment 22 Rex Dieter 2010-06-16 11:32:51 EDT
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.
Comment 23 Felipe Contreras 2010-06-16 11:41:45 EDT
(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
Comment 24 Christoph Wickert 2010-06-16 11:54:45 EDT
You need to subscribe to the mailing list. How else would you get the replies to your mail?
Comment 25 Felipe Contreras 2010-06-16 12:35:21 EDT
(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).
Comment 26 Kevin Fenzi 2010-06-20 20:14:49 EDT
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.
Comment 27 Mamoru TASAKA 2010-06-30 05:53:45 EDT
I suggest to once close this as NOTABUG.
Comment 28 Kevin Fenzi 2010-07-04 16:23:25 EDT
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.
Comment 29 Felipe Contreras 2010-08-05 05:39:55 EDT
(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?
Comment 30 Kevin Fenzi 2010-08-08 17:15:48 EDT
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
Comment 31 Kevin Fenzi 2010-08-23 12:05:00 EDT
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).
Comment 32 Felipe Contreras 2010-08-23 12:52:02 EDT
(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.
Comment 33 Orcan Ogetbil 2010-08-23 13:16:46 EDT
(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.
Comment 34 Felipe Contreras 2010-08-23 15:04:53 EDT
(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.
Comment 35 Orcan Ogetbil 2010-08-23 19:48:33 EDT
(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?
Comment 36 Kevin Fenzi 2010-08-23 20:28:12 EDT
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.
Comment 37 Chen Lei 2010-08-23 22:22:55 EDT

(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.
Comment 38 Peter Robinson 2010-08-31 12:24:49 EDT
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?
Comment 40 Jens Petersen 2010-09-15 21:06:01 EDT
(This bug is a long read... was the idea of a filesystem package
to own the dir discussed/rejected?)
Comment 41 Felipe Contreras 2011-02-04 16:18:09 EST
(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).
Comment 42 Fedora Update System 2011-02-14 11:10:14 EST
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
Comment 43 Fedora Update System 2011-02-14 12:42:02 EST
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
Comment 44 Christoph Wickert 2011-02-14 12:52:45 EST
Rick, the bug you fix with your updates is bug 604339 and not this one. Please edit your updates.
Comment 45 Fedora Update System 2011-02-15 12:28:09 EST
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
Comment 46 Felipe Contreras 2011-05-25 08:29:49 EDT
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
Comment 47 Christoph Wickert 2011-05-25 08:57:26 EDT
(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.
Comment 48 Felipe Contreras 2011-11-16 12:40:02 EST
Updated for Fedora 16.

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