| Summary: | easily clean the system of orphaned dependencies | ||
|---|---|---|---|
| Product: | PackageKit | Reporter: | David Prieto <frandavid100> |
| Component: | General | Assignee: | Richard Hughes <richard> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | medium | CC: | cosimoc, grfgguvf, jw+debian, mail |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
David Prieto
2008-09-30 04:37:21 UTC
I don't think the users should ever have to "clean the system" -- look at the profiles on http://packagekit.org/pk-profiles.html -- none of those people should be cleaning up anything. True, the user shouldn't have to worry about cleaning the system. But I think that only means that PK should take care of orphaned packages for him, meaning it should uninstall them automatically. Would that be a good idea? The argument against not doing it automatically is that even if a package was automatically installed the user may have come to rely on it, and if it is removed automatically they get no chance to keep it. Also, since they never explicitly installed the package they may not even know what the name of the package is, and so may have trouble getting it back, even if they can work out where it went. Thanks, James I understand, but that leaves the user no way to clean the system, and the system will build up more and more junk / orphaned dependencies with every installed /uninstalled package. It's one thing that the user "doesn't have to worry" about cleaning his computer, and an entirely different one that he doesn't even get the option to do so. Back to the profiles on the profile page. Alright, so we don't want them to "have to" clean the system. So we don't want them some automatically installed package and be unable to retrieve it. A "Clean the system", "Remove unneeded programs" or similar entry in the "System" menu certainly wouldn't harm them or force them to worry about anything, they can safely ignore it. And at the same time, PK would let users like me keep our systems clean. Would that be an acceptable alternative? "So we don't want them TO LOSE some automatically installed package" Sorry, I somehow dropped a couple words from that sentence. It's not no way to do it, there are existing ways, but I agree that there
would be no way to do it within packagekit if it wasn't done automatically.
I'm not sure what the right answer is.
A couple more thoughts:
* Users will probably want to "clean their system" it makes them think
it will run faster etc., even if it has no real effect. The lack of
it may make them wonder where the feature is. Perhaps this isn't a
trait that should be catered for.
* An Ubuntu develoepr has been working on "system-cleaner" this cycle,
which is intended to do many things like this, including the orphaned
package removal I believe. Some of it would need porting to other
package managers, but knowing the developer, and a bit of the architecture
I believe this should be quiet easy. Perhaps putting effort in to doing
it in one place would be a good idea.
Thanks,
James
"Users will probably want to "clean their system" it makes them think it will run faster etc" An easy solution would be to make it clear in the progress dialogue. Over the progress bar there could be a short message like "removing unneeded programs to free disk space". I think there would be no getting that wrong. I really think this should be handled within PK somehow. Having to install an external program for such a basic feature seems totally overkill to me. But I think I might be misunderstanding your last paragraph, I'm not sure whether you meant this system cleaner program should take care of orphaned packages, or that its functionality should be somehow incorporated into PK. I think this is an essential feature. A few thoughts: a) There should be no option to do this cleanup, it should be automatic b) Packages should be marked in the repositories by the distributions as something like Backend vs Frontend, for example a shared library is Backend, an application is Frontend c) Installed packages should be marked as Requested or AutomaticDependency d) Following from above, when doing the cleanup, only AutomaticDependency Backend packages that are no longer depended upon should be removed. This will avoid removing something that might have been installed automatically but then found useful e) Cleanup should probably not done too often, only periodically f) User-interface is not needed for this, I think, there should be no progress bar, it should be a silent background task What do yous think? g) About the Backend vs Frontend distinction, there could be some heuristics, like relying on the RPM/Deb package group, or considering lib* packages as Backend, with a few exceptions, though this is fragile Hi, Considering things as Backend vs. Frontend would be an improvement, but it's not going to rule out every case. It's possible that I come to depend on a feature in an application that is only there because of an automatically installed backend package, for instance if the application dlopen()s it. I'm not sure if other package managers have this automatic install tracking, but the backend/frontend thing should be discussed with the dpkg/apt/aptitude developers if it was to be considered for packagekit. Thanks, James AFAIK aptitude removes orphaned dependencies by default. How well does this work? Could be nice to make use of atime to find not long used software. Yes, aptitude (and apt-get) remove orphaned deps. It works very well, I never had a needed package removed on Debian. Also, urpmi on Mandriva also can remove orphaned deps. But it is less polished and once it wanted to remove glibc(!). Fedora has a 'package-cleanup --orphans' command but as yum wasn't designed for this it can't intelligently work out which packages are really unneeded. Then there's FreeBSD Ports+Packages system, which includes pkg_cutleaves but that has the same shortcomings as Fedora. Does anyone know about the situation on Solaris, Gentoo, Conary, etc? We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.