Mailinglist Archive: opensuse-softwaremgmt (13 mails)
| < Previous | Next > |
Re: [softwaremgmt] software manager: provide aid in removing unused libraries (uninstall)
- From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
- Date: Sun, 30 Sep 2007 12:01:18 +0200
- Message-id: <46FF73EE.9030308@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Maciej Pilichowski wrote:
[...]
> Technically I can imagine it could be done by building reverse
> dependency tree and show all leaves. The drawback of such approach
> would be in including main apps too :-) Maybe it could be solved by
> checking if:
> 1) there is an executable in the package
/usr/bin/foo-config
is an executable too, but it's only in -devel packages, so that's
already an exception.
> 2) any of the files in the package were accessed lately
That's going to be very expensive to compute (or rather, very
time-consuming and lots of I/O).
> 3) did user install it explictly or it was SM call (fullfilling
> requirements)
It must be tracked by the package manager because RPM won't tell you.
And then you get into the problem that it would only work if the user
always uses yast (or maybe it could be done in libzypp).
If he uses "rpm -i" or smart or yum or whatever else just once, it won't
be tracked.
IMO point 3) is not feasible.
And the problem in the first place is that you can't just use "rpm
- --whatrequires" to find out whether a package is needed or not, because
rpm only reports Requires: with package names there. But must of the
dependencies are on filenames (e.g. "libxml2.so.2" or "/bin/bash").
As an example, take libxml2.
It's not sufficient to do
$ rpm -q --whatrequires libxml2
You must also list all Provides of that package:
$ rpm -q --provides libxml2
libxml2.so.2()(64bit)
libxml2 = 2.6.26-26
and then apply some fuzzy logic to also do
$ rpm -q --whatrequires 'libxml2.so.2()(64bit)'
And that's just for shared libs.
So.. certainly feasible in theory but not as simple as it might seem.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFG/3Pur3NMWliFcXcRAsJgAJ4scE520B9AxTeZL4bg6BDmO637QgCgmyto
vILMhTNbUMLciclLQb9XHUQ=
=C9Hi
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx
Hash: SHA1
Maciej Pilichowski wrote:
[...]
> Technically I can imagine it could be done by building reverse
> dependency tree and show all leaves. The drawback of such approach
> would be in including main apps too :-) Maybe it could be solved by
> checking if:
> 1) there is an executable in the package
/usr/bin/foo-config
is an executable too, but it's only in -devel packages, so that's
already an exception.
> 2) any of the files in the package were accessed lately
That's going to be very expensive to compute (or rather, very
time-consuming and lots of I/O).
> 3) did user install it explictly or it was SM call (fullfilling
> requirements)
It must be tracked by the package manager because RPM won't tell you.
And then you get into the problem that it would only work if the user
always uses yast (or maybe it could be done in libzypp).
If he uses "rpm -i" or smart or yum or whatever else just once, it won't
be tracked.
IMO point 3) is not feasible.
And the problem in the first place is that you can't just use "rpm
- --whatrequires" to find out whether a package is needed or not, because
rpm only reports Requires: with package names there. But must of the
dependencies are on filenames (e.g. "libxml2.so.2" or "/bin/bash").
As an example, take libxml2.
It's not sufficient to do
$ rpm -q --whatrequires libxml2
You must also list all Provides of that package:
$ rpm -q --provides libxml2
libxml2.so.2()(64bit)
libxml2 = 2.6.26-26
and then apply some fuzzy logic to also do
$ rpm -q --whatrequires 'libxml2.so.2()(64bit)'
And that's just for shared libs.
So.. certainly feasible in theory but not as simple as it might seem.
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFG/3Pur3NMWliFcXcRAsJgAJ4scE520B9AxTeZL4bg6BDmO637QgCgmyto
vILMhTNbUMLciclLQb9XHUQ=
=C9Hi
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-softwaremgmt+help@xxxxxxxxxxxx
| < Previous | Next > |