[Bug 222326] Review Request: gxine - GTK frontend for the xine multimedia library

bugzilla at redhat.com bugzilla at redhat.com
Thu Jan 18 09:38:01 UTC 2007


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gxine - GTK frontend for the xine multimedia library


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222326





------- Additional Comments From rc040203 at freenet.de  2007-01-18 04:37 EST -------
(In reply to comment #14)
> (In reply to comment #13)
> > /me votes for "%{_libdir}/mozilla/plugins" as that scheme is used by other
> > packages already 
This doesn't work do to bugs in rpm (Ville: Does this still apply, or this rpm
finally been fixed).

> Well, I will think about it. But about the spin you talk about - you can have
> gxine without firefox installed. The "Require: firefox" is in the -mozplugin
> subpackage.
The problem is not firefox, the problem is removing "%{_libdir}/mozilla/plugins"
the directory, when it's not needed anymore.

That is what I wrote a couple of days ago in another package's review:

- If several packages share a common directory, and if they depend on each other
in a strict hierarchy, then letting the "root package" own this dir is sufficient.
- If they don't depend on each other in a strict hierarchy, all of the packages
must own this directory.

The former doesn't apply to gxine-mozplug => Only the latter is applicable.

"Requires: firefox" would be a hack to force the former approach, though this,
strictly speaking is incorrect and too strict (It's the same "hack" why packages
providing *.pc must "Require: pkgconfig" and packages providing aclocal/*.m4
must "Require: automake". Both these "Require"-ments are hacks/band-aids and
actually wrong, but provided rpm persists to be unfixed/unmaintained, these are
"easy hacks").




-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.




More information about the Fedora-package-review mailing list