Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 901645 - cannot be deinstalled as dependency hell is unleashed when trying
Summary: cannot be deinstalled as dependency hell is unleashed when trying
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 17
Hardware: Unspecified
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: depchain
TreeView+ depends on / blocked
 
Reported: 2013-01-18 18:02 UTC by udo
Modified: 2013-04-23 17:48 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-22 12:39:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description udo 2013-01-18 18:02:17 UTC
Description of problem:
PK cannot be fully uninstalled due to dependency
PK cannot be disabled easily
So PK is not modular enough and not user friendly enough

Version-Release number of selected component (if applicable):
fedora-current

How reproducible:
# rpm -e PackageKit-0.7.5-1.fc17.x86_64 PackageKit-glib-0.7.5-1.fc17.x86_64 PackageKit-yum-0.7.5-1.fc17.x86_64
error: Failed dependencies:
	libpackagekit-glib2.so.14()(64bit) is needed by (installed) gnome-settings-daemon-3.4.2-4.fc17.x86_64

  
Actual results:
See above

Expected results:
clean uninstall

Additional info:
Fedora components/packages should be modular: easy to install and uninstall without unnecessary dependencies
Fedora components/packages should have an ON/OFF switch

Comment 1 Richard Hughes 2013-01-21 09:55:39 UTC
(In reply to comment #0)
> Description of problem:
> PK cannot be fully uninstalled due to dependency

You can't uninstall upower, colord, systemd, etc.

> PK cannot be disabled easily

Why do you want to do that?

> So PK is not modular enough and not user friendly enough

I don't share your working for those conclusions, sorry.

Richard.

Comment 2 udo 2013-01-21 14:09:22 UTC
PK is not in the upower, colord, systemd.
upower is optional and should be separate. Your CPU migth not even be suported!
systemd is obvious, despite the bugs, most of the biggest have been fixed, it was not yet ripe for release. Hard to circumvent though.
colord I do not even use and it balks about two identical webcams. Not good, needs to go.

PK I do not need as I know how to run yum manually from time to time.

I am the user.
I am not asking something impossible.
Just a tiny feature:


PK needs a CLEAR ON/OFF switch.
PK needs to be uninstallable.

Those are very basic functionalities which should be in every package/component.
Please FIX.
I even want to pay for this basic stuff. (!!)

Comment 3 Rex Dieter 2013-01-21 14:43:15 UTC
You can get 90% of disabling PK, by simply configuring your gui client, gpk-prefs or apper (kde), to never check for updates.

Or uninstall said gui frontend (gnome-packagekit and/or apper), and you'll never be bothered by it either.

The maintainers of this component have carefully considered your request to make PK fully removable, and deemed it not practical to implement.  

It's fine if you disagree, but re-opening this bug again is not a constructive way forward.  If you wish to pursue further discussion, I'd recommend other avenues,
http://fedoraproject.org/wiki/Communicating_and_getting_help
probably the fedora devel mailing list would be most appropriate.

Thank you.

Comment 4 udo 2013-01-21 14:52:27 UTC
90% is not 100%.
'Not practical to implement' so...
The set of features is totally reasonable and even practical towards the user.
Who designed stuff this way so that it was not practical to implement such a carefully decided upon basic set of features?

Do they disagree on my carefully decided basic set of features?
Or do they agree but do they uphold the opinion that it is to much work in this specific case?
Who are 'they'?

I do not disagree. My case here is the goal that all packages should strive for.
That is the truth. You'll have a hard time explaining otherwise.

The project is not flexible enough for my wishes so if a developer does not understand or even has the nerve to say he thinks so then it is his issue unleashed upon the users.
See the housekeeping process which shows numerous bugs that are not solved or even not responded to within the time of two Fedora releases.

Please FIX the issues.

Comment 5 Richard Hughes 2013-01-22 12:39:58 UTC
(In reply to comment #4)
> Who designed stuff this way so that it was not practical to implement such a
> carefully decided upon basic set of features?

Me.

> Do they disagree on my carefully decided basic set of features?
> Or do they agree but do they uphold the opinion that it is to much work in
> this specific case?
> Who are 'they'?

Me.

> I do not disagree. My case here is the goal that all packages should strive
> for.
> That is the truth. You'll have a hard time explaining otherwise.

Sure, the truth is that you can't remove systemd, colord, PackageKit or upower from a general purpose operating system. Sorry, that's just the reality we live in.

> The project is not flexible enough for my wishes so if a developer does not
> understand or even has the nerve to say he thinks so then it is his issue
> unleashed upon the users.

Sure, it's my issue.

> See the housekeeping process which shows numerous bugs that are not solved
> or even not responded to within the time of two Fedora releases.

Right, I do a lot of the PackageKit in my own time. I have limited free time as I have a new baby. Any help writing code and fixing bugs is very welcome.

Comment 6 udo 2013-01-22 14:06:52 UTC
PLEASE rethink what you are doing and who you are doing that for.
Please consider THEIR perspective.
PLEASE FIX the stuff I mentioned.


The 'reality' that we cannot remove certain stuff cannot be used as an argument, it merely explains how BAD the situation is w.r.t. modularity.

PLEASE FIX the stuff I mentioned.

Comment 7 Rex Dieter 2013-01-22 14:18:45 UTC
See comment #3 if you want further dialog.

bugzilla is *not* the place for a discussion like this.

Comment 8 udo 2013-01-22 15:26:17 UTC
I am not discussing. You are not understanding well enough.
You don't even say 'I see your point, but I cannot do that right now..' or similar.

Comment 9 Rex Dieter 2013-01-22 15:48:37 UTC
I did say we "have carefully considered your request" in comment #3 .  Please do consider that as "I see your point..." as well.

Comment 10 udo 2013-01-22 16:10:21 UTC
Then I misunderstood that part.
Still, the 'CANTFIX' does not offer any perspective that the two basic issues I mentioned will ever be fixed.
So no future date, or some conditional explanation or whatever.

Comment 11 Rex Dieter 2013-01-22 17:33:59 UTC
WONTFIX/CANTFIX means to the feature you requested as-is, will (most likely) not ever get implemented.  Developers in feature requests (and bugzilla) have no responsibility to justify their judgements to your satisfaction.  They know the code and implementations fairly well, hopefully, and deserve some level of trust to know what they are talking about.

That said, I have now suggested on 3 separate occasions that if you don't accept that resolution, you can take up further discussion in other more appropriate venues (like fedora -devel list).

This will likely be my last comment here on this bug, unless any new information (that hasn't already been mentioned) comes to light.

Comment 12 Peter Robinson 2013-04-23 17:48:36 UTC
(In reply to comment #10)
> Then I misunderstood that part.
> Still, the 'CANTFIX' does not offer any perspective that the two basic
> issues I mentioned will ever be fixed.
> So no future date, or some conditional explanation or whatever.

You can remove PackageKit in F-18+ without issue, you can do the same in F-19 too.


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