Red Hat Bugzilla – Bug 694169
phonon dependencies prevent running a reasonable Fedora without PackageKit
Last modified: 2012-01-01 08:13:55 EST
Description of problem:
phonon-backend-gstreamer now depends on PackageKit making it impossible to run Fedora without PackageKit installed. This happened with a regular update of Fedora 14.
Here is part of the dependency chain:
PackageKit <- PackageKit-gstreamer-plugin <- phonon-backend-gstreamer <- phonon <- tons of things
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to remove PackageKit, rpm -e `rpm -qa | grep -i packagekit`
2. Alternately, try to update Fedora system using yum that does not currently have PackageKit installed. Yum will now install it.
PackageKit is now required for many packages.
Should be able to uninstall PackageKit completely. Several weeks ago this could be done. I am aware of nothing else outside of the PackageKit-* packages that depend on PackageKit.
Those of us who do not want ordinary users to install packages have been simply uninstalling PackageKit. If you don't want users installing software or running updates it is not needed. This dependency prevents this.
Why is phonon trying to install software anyway? If it requires other packages then they should be listed as dependencies. This breaks the current package management paradigm. If the software phonon is trying to install is found in non-fedora repositories then this breaks the Fedora philosophy. Users should have to add those repositories themselves.
So, I was able to avoid PackageKit by removing phonon-backend-gstreamer and installing phonon-backend-xine.
Looks like phonon depends on phonon-backend, but there is no phonon-backend package, it just needs phonon-backend-xine or else phonon-backend-gstreamer
platte:~$ rpm -qR phonon | grep backend
phonon-backend(x86-64) >= 4.4
platte:~$ rpm -qa | grep -i phonon-backend
Is this right? Seems strange to me.
In any case, I am still concerned that phonon-gstreamer-backend requires a package management tool and if phonon-backend-xine does the same thing then I will have no option but to install PackageKit. Thanks!
Sorry, but "a reasonable Fedora without PackageKit" is an oxymoron. PackageKit is an integral part of at least graphical installations of Fedora.
> Those of us who do not want ordinary users to install packages have been simply
> uninstalling PackageKit.
The default policies already don't allow ordinary users to install new packages nor to remove packages without the root password.
You can also ban them from doing system updates by changing the PolicyKit policies. But I don't see being allowed to update already installed packages from already-configured signed repositories as a security risk. And besides, if only PackageKit is installed and no GUI, chances are your users won't even try anyway. But as I said, the policy can be changed through PolicyKit.
> Why is phonon trying to install software anyway?
Automatic GStreamer plugin installation.
If you don't want your users to hit this dialog and be unable to install the required codecs (because PackageKit will ask them for the root password, or because KPackageKit is not installed), you'll have to install the third-party codecs for them. (And I'm probably not supposed to tell you that the commonly needed plugin packages are called gstreamer-plugins-ugly, gstreamer-plugins-bad and gstreamer-ffmpeg and can be found in RPM Fusion Free. ;-) ) We cannot ship them in Fedora (and thus we also cannot install them by default in Fedora) for patent reasons.
Thanks for the prompt reply. I would have to respectfully argue that "a reasonable Fedora without PackageKit" is not an oxymoron... or at least wasn't until now. Two weeks ago you could run
rpm -e `rpm -qa | grep -i packagekit`
on a default install and it would remove everything PackageKit without a hitch. phonon-backend-gstreamer is the first package that I am aware of that depends on PackageKit and since KDE depends on phonon one now HAS to have PackageKit to have KDE. This wasn't the case before.
So, I know the debate has already been had before but I just want to mention that we really dislike having PackageKit on our systems because we have 300+ Fedora machines in a computer lab setting that are all exact clones of each other. When the users have prompts and notices to update and install packages it just confuses them... especially if we require the root password. And, of course, updating from signed repos isn't a security concern but it ruins our environment of exactly cloned machines. We opt to install updates from a controlled central location so that everything stays the same. I would/do happily install the codecs for our users and since the machines are clones it works out neatly.
I certainly understand your intentions but I have to say that I would prefer users just get proprietary software from RPM Fusion or elsewhere themselves. Or at least install these codecs in home directories (like a firefox plugin) so that some users could choose to use the codecs on a given system while others can choose to stay free proprietary software. If PackageKit does it then if one user installs the codecs on a system then everyone gets them without a choice. Fedora is a multi-user system after all.
In any case, it sounds like Fedora has approved this so all I can do is give my two cents. Thanks again!
As for why we added this dependency to Phonon, the reasons are twofold:
1. Nothing else in KDE dragged in PackageKit-gstreamer-plugin. Something has to require it so this feature just works for users (and here I mean home users, not your users) upgrading their Phonon.
2. Phonon-GStreamer crashes if it tries to install a codec and there's no codec installation plugin installed: https://bugs.kde.org/show_bug.cgi?id=262308 . This dependency also works around that crash.
It's always hard for us to make everyone happy. We have to consider very different use cases:
* the home user who wants his software to "just work". This is the target use case for features like the automatic codec installation discussed here. Typically, in those situations, we have a desktop or laptop/notebook machine used by one user or at most one family (who can usually agree on what needs to be installed).
* the multi-user deployment. Here, we have many workstations, many users and a central administrator. This is your use case.
* the server. Single machine, many users, no (or at most limited and slow, e.g. X11 forwarding) graphical interface, most users typically do not have shell access, but only access services such as HTTP.
The constraints of those types of deployment are very different, and sometimes a feature designed for one won't work all that well for the others. I'm well aware of this problem. But I don't think we have a good solution to avoid this dependency in this case.
(And FYI, the maintainer who added this dependency to the package is also a system administrator like you.)
One possible solution would be to:
1. get the crash (https://bugs.kde.org/show_bug.cgi?id=262308) fixed and
2. move the dependency from phonon-backend-gstreamer to kpackagekit.
That should address your issue and still get the PackageKit-gstreamer-plugin dragged in. The drawback would be that KPackageKit would then depend on GStreamer, which could also make some people unhappy.
But as long as kde#262308 is not fixed, i.e. as long as Phonon-GStreamer crashes when the PackageKit-gstreamer-plugin is not installed, there isn't much we can do.
I agree with the sentiment expressed in comment #6 , and would add it was phonon upstream's recommendation to add the dependency.
In a perfect world, we wouldn't have to workaround the crash that way and/or we could use soft-dependencies to pull pk-gst in (but still allow it to be optional).
I also like the idea in comment 6.
Alternately, is it difficult to have PackageKit-gstreamer-plugin included as a default package in KDE? I am naive as to how that works but it seems like maybe the dependency wouldn't be necessary if it were included by default. That way it would just work with a fresh install but could still be removed.
Of course, this would have to be in a future release of Fedora since users of 14 still need it and would require the crash to be fixed.
I would be happy just knowing that it could be uninstalled again in a future release.
I appreciate that you guys consider all the use cases of Fedora. I know it's not always possible to make everyone happy but I think that taking feedback from various places is a big part of what makes Fedora great.
*** Bug 696304 has been marked as a duplicate of this bug. ***
Turns out the crasher bug that was one justification for these dependency has been fixed. Upstream still does recommend keeping the dep, however, so auto-codec installs can continue to "just work".
that said, we can re-consider now.
Looks like we're not the only ones requiring PackageKit now, GNOME also requires it in F15 (even gdm drags it in), so I don't think trying to do anything about this "issue" is useful now.
*** This bug has been marked as a duplicate of bug 699263 ***
So what? "The others are doing this, too" is a lame and childish excuse for what you do.
I'm now reopening this bug for further discussion. Please don't close it duplicate of 699263 again because that bug is something completely different. When too many packages depend on foo, the problem is not the foo package but the ones depending on it and to fix this we need to file bugs on the individual packages rather than on foo.
(In reply to comment #2)
> Sorry, but "a reasonable Fedora without PackageKit" is an oxymoron. PackageKit
> is an integral part of at least graphical installations of Fedora.
Claim. Proof or reason?
> But I don't see being allowed to update already installed packages
> from already-configured signed repositories as a security risk.
Not necessarily a security risk but a high probability that updates will break a system, especially KDE updates.
> Automatic GStreamer plugin installation.
This is an optional feature rather than a required base functionality. It is not a runtime dependency of the plugin itself, therefor the dependency should not be hardcoded in the package. Why not handle this with a conditional in comps?
The goal of the dependency is to have automatic codec installation just work (well, once bug 697618 is fixed, a regression, IMHO we shouldn't have pushed Phonon 4.5.0 without that fixed!).
Comps is not a solution because it doesn't work for regular F14 updates nor for F14→F15 or F13→F15 upgrades.
(In reply to comment #13)
> The goal of the dependency is to have automatic codec installation just work
> (well, once bug 697618 is fixed, a regression, IMHO we shouldn't have pushed
> Phonon 4.5.0 without that fixed!).
98% of all people will have PackageKit installed anyways. Has anybody tested what happens if it's not installed?
> Comps is not a solution because it doesn't work for regular F14 updates nor for
> F14→F15 or F13→F15 upgrades.
Again, most people will have PackageKit installed, so there is no need for this dependency. But mspeaking of updates: On the other hand we should not have a phonon update in a stable release that adds a new dependency.
> 98% of all people will have PackageKit installed anyways.
But not PackageKit-gstreamer-plugin, which is what the dependency is on. PackageKit is only an indirect dependency. The PackageKit-gstreamer-plugin wasn't required by anything in KDE previously.
> Again, most people will have PackageKit installed, so there is no need for this
> But speaking of updates: On the other hand we should not have a phonon update
> in a stable release that adds a new dependency.
IMHO it's quite the opposite: there's a new feature that needs a new dependency, we need it dragged in or the feature will not work.
It's actually quite frequent that updates drag in new dependencies, e.g. those python-fedora and fedora-packager updates regularly drag in new Python modules.
I was the one that re-opened this, with the intention of at least discussing it at a kde-sig meeting. We'll do that tomorrow, and I'll update this bug status then.
But considering the new facts (bug 699263, closed as NOTABUG), is it even worth discussing this anymore?
PackageKit is now a core library to the same extent e.g. PolicyKit, udisks or pulseaudio-libs are. Everything depends on it.
(In reply to comment #15)
> > 98% of all people will have PackageKit installed anyways.
> But not PackageKit-gstreamer-plugin, which is what the dependency is on.
This is not true. PackageKit-gstreamer-plugin is default in the 'Sound and Video' group, see http://git.fedorahosted.org/git/?p=comps.git;a=blob;f=comps-f14.xml.in;h=e5089754747f2722f798ef108018024cfa92bd09;hb=HEAD#l5353
> PackageKit is only an indirect dependency. The PackageKit-gstreamer-plugin
> wasn't required by anything in KDE previously.
Then this dependency should not be added during a release. Remember, this bug was filed against F14.
What is the rationale of providing different phonon backend packages if user are forced to install one anyway? Things like this are supposed to be handled through comps rather than hardcoded requires in the packages.
> > But speaking of updates: On the other hand we should not have a phonon update
> > in a stable release that adds a new dependency.
> IMHO it's quite the opposite: there's a new feature that needs a new
> dependency, we need it dragged in or the feature will not work.
New features should not be added to a stable release, this is what the development cycle is for.
> It's actually quite frequent that updates drag in new dependencies, e.g. those
> python-fedora and fedora-packager updates regularly drag in new Python modules.
Again, this is the childish "But the others are doing it, too" excuse. ;)
Apart from that I think python-fedora and fedora-packagers are developer tools that cannot be compared to end-user packages like this one.
(In reply to comment #17)
> But considering the new facts (bug 699263, closed as NOTABUG), is it even worth
> discussing this anymore?
That bug was closed DUPLICATE of bug 699348 and will be investigated further. The fact that two people added themselves as CC to this bug just after I have filed it shows that that many people consider this dependency problematic.
> PackageKit is now a core library to the same extent e.g. PolicyKit, udisks or
> pulseaudio-libs are. Everything depends on it.
Repeating false statements doesn't make them right. This is just a self-fulfilling prophecy: "We depend on it because it is a core library because we depend on it..."
(In reply to comment #17)
> But considering the new facts (bug 699263, closed as NOTABUG), is it even worth
> discussing this anymore?
BTW: That bug was about the gnome.integration, not about gstreamer. so definitely something completely different than we are discussing here.
> This is not true. PackageKit-gstreamer-plugin is default in the 'Sound and
> Video' group
"Sound and Video" is not installed by default on the KDE spin. (Stuff like brasero or totem, which is default there, has no business being on the KDE spin.)
> What is the rationale of providing different phonon backend packages if user
> are forced to install one anyway?
Users are not forced to install phonon-backend-gstreamer (in fact, phonon-backend-xine is still the default on F14!), but it is installed by default on the KDE spin, exactly to give users a choice.
> BTW: That bug was about the gnome.integration, not about gstreamer. so
> definitely something completely different than we are discussing here.
The end effect is the same, PackageKit gets dragged in as an indirect dependency.
update: kde-sig met today an affirmed the status quo to keep the hard dependency here (though it was a little contentious and not unanimous).
*** Bug 755539 has been marked as a duplicate of this bug. ***
So we agreed in the KDE SIG meeting to drop this dependency in Rawhide, which was actually already done because of some dependency issues in PackageKit, but we decided to make this change permanent.
Rationale: Now that phonon-backend-gstreamer is the default, we're actually installing PackageKit-gstreamer-plugin by default for new users. As for upgrades, they should already be getting the PackageKit-gstreamer-plugin dragged in by default due to the current hard dependency.
That said, we are uncomfortable with the idea of removing the dependency in Fedora 16 at this time because of users upgrading from earlier releases (especially Fedora 14 which still defaulted to phonon-backend-xine).
*** Bug 769009 has been marked as a duplicate of this bug. ***