Mailinglist Archive: yast-devel (116 mails)

< Previous Next >
Re: [yast-devel] introduce a package history to remove obsolete packages
  • From: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 10 Jun 2008 16:04:39 +0100
  • Message-id: <1213110279.4329.18.camel@xxxxxxxxxxxx>
Hi,

I like the idea, though you're making it more complicated than it
needs, but those dependencies are only dead disk space. If they conflict
with something, they'll be removed or upgraded then.

I think there are more important flaws with Suse's package system.
There is no layers in there which would make stuff like what you're
talking about simpler, and could allow for some interesting uses. Of
course, there is a certain terminology that packagers tend to respect.
But most fundamentally, it would be cool if the packages database was
the directory structure itself. This is when the clutter gets in: a lot
of people don't want to be bothered about doing a RPM package, and you
get a mess, because stuff gets installed all over /user, and this can
actually result in conflict if you don't clean it up.

Cheers,
Ricardo

Sex, 2008-06-06 às 20:33 +0100, Hanno Svoboda escreveu:
I use yast in openSUSE 10.3 to manage my software packages. I like to explore
many different FLOSS projects and install quite a lot of software which I
remove later on. A big problem for me is that my installation becomes more
bloated after a while, because libraries and dependencies which came with the
installed software can't be identified and are not automatically removed
(probably for a good reason). Therefor I like to propose an idea, which could
potentially solve this issue:

1. Create a history of installed packages with following information:
When
Package X was installed, also packages Y + Z were installed

2 If the user removes X, Y, or Z, YAST should asks: Should the other two
packages (X, Y and/or Z) also be removed as they have no other dependencies?

3. If the user decides not to remove them or they have dependencies on W
from
a different installation time point, they should be tagged as potentially
obsolete.

4. Removal of W should trigger again: Should Y and Z also be removed as
they
have no other dependencies and were marked as potentially obsolete?

5. If further dependencies exist or the user decides to keep them,
Continue
at 3. Either the loop ends in package removal or at stable state 3.



I hope this is not too confusing and this package bloating issue can be
tackled. I am happy to clarify or maybe somebody else has a better (simpler)
idea. If you think that sort of makes sense, you can read on some refinements
below.

Hanno

PS: Unfortunately, I cannot program and can't produce any poof of principle
implementation. I think their is no big logical error in it, but I am sure it
needs some polishing here and there.



-----------------

REFINEMENTS to the idea above, which make it more complicated and powerful.
Points 2, 4 and 5 remain as they are.

1. Make a history of installed packages, which hold following
information:
When Package X was installed, also packages Y + Z were installed which are in
an dependency relation to X.
If the dependency criterion is not used, unrelated software that was
installed
at the same time (e.g. two completely unrelated programs) would fall under
the
removal category, which is unwanted.


3. If the user decides not to remove them they should be tagged as
potentially "obsolete without dependencies". If they have dependencies on W
from a different installation time point, they should be marked as "obsolete
with dependencies". The user could use an option in YAST to remove all
obsolete packages in the installation which are tagged "obsolete without
dependencies".


--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
References