how to determain those no longer required packages

[Ray Chen]

I'm reading APT and YUM source codes recently, and met the following
question:

for class apt.package.Package, there are a function "isAutoRemovable",
which means:
http://apt.alioth.debian.org/python-apt-doc/apt/package.html?highlight=isaut...

Return True if the package is no longer required.

If the package has been installed automatically as a dependency
        of another package, and if no packages depend on it anymore, the
        package is no longer required.

Do YUM codes have the same function as 'isAutoRemovable' feature??  or
how to determine such no longer required rpm packages using yum CLIs?

Thanks,
Ray

[Michel Alexandre Salim]

On Sat, Aug 29, 2009 at 5:54 AM, Ray Chen wrote:
> If the package has been installed automatically as a dependency
>        of another package, and if no packages depend on it anymore, the
>        package is no longer required.
>
> Do YUM codes have the same function as 'isAutoRemovable' feature??  or
> how to determine such no longer required rpm packages using yum CLIs?

Try package-cleanup from yum-utils.

Cheers,

[Ray Chen]

Thanks, package-cleanup is what I want:)

-Ray

在 2009-08-29六的 03:29 -0400，Michel Alexandre Salim写道：
> On Sat, Aug 29, 2009 at 5:54 AM, Ray Chen wrote:
> >    If the package has been installed automatically as a dependency
> >    of another package, and if no packages depend on it anymore, the
> >    package is no longer required.
> >
> >
> > Do YUM codes have the same function as 'isAutoRemovable' feature??  or
> > how to determine such no longer required rpm packages using yum CLIs?
>
> Try package-cleanup from yum-utils.
>
> Cheers,
>
> -- 
> Michel

[Milos Jakubicek]

rpmreaper may be handy for that too...

Regards,
Milos

Dne 29.8.2009 19:07, Ray Chen napsal(a):
> Thanks, package-cleanup is what I want:)
>
> -Ray
>
> 在 2009-08-29六的 03:29 -0400，Michel Alexandre Salim写道：
> > On Sat, Aug 29, 2009 at 5:54 AM, Ray Chen  wrote:
> > >     If the package has been installed automatically as a dependency
> > >     of another package, and if no packages depend on it anymore, the
> > >     package is no longer required.
> > >
> > >
> > > Do YUM codes have the same function as 'isAutoRemovable' feature??  or
> > > how to determine such no longer required rpm packages using yum CLIs?
> >
> > Try package-cleanup from yum-utils.
> >
> > Cheers,
> >
> > --
> > Michel

[Ray Chen]

rpmreaper is NOT installed by default, I want use yum API in scripts to
remove unnecessary packages. The key is that how to determine the
unnecessary packages. so that I can remove safely to save disk.

Would you like show me more details?? What packages are unnecessary
packages?

Thanks,
Ray

在 2009-08-29六的 13:46 +0200，Milos Jakubicek写道：
> rpmreaper may be handy for that too...
>
> Regards,
> Milos
>
> Dne 29.8.2009 19:07, Ray Chen napsal(a):
> > Thanks, package-cleanup is what I want:)
> >
> > -Ray
> >
> > 在 2009-08-29六的 03:29 -0400，Michel Alexandre Salim写道：
> > > On Sat, Aug 29, 2009 at 5:54 AM, Ray Chen  wrote:
> > > >     If the package has been installed automatically as a dependency
> > > >     of another package, and if no packages depend on it anymore, the
> > > >     package is no longer required.
> > > >
> > > >
> > > > Do YUM codes have the same function as 'isAutoRemovable' feature??  or
> > > > how to determine such no longer required rpm packages using yum CLIs?
> > >
> > > Try package-cleanup from yum-utils.
> > >
> > > Cheers,
> > >
> > > --
> > > Michel

[Milos Jakubicek]

Dne 29.8.2009 22:46, Ray Chen napsal(a):
> rpmreaper is NOT installed by default, I want use yum API in scripts to
> remove unnecessary packages.

Rpmreaper doesn't use yum API, it's pure rpm-based. For usage refer to 
the relevant manpage (man rpmreaper), you might be especially 
insterested in something like "rpmreaper -lv | grep LEAF"

Cheers,
Milos

[Seth Vidal]

On Sun, 30 Aug 2009, Ray Chen wrote:
> Thanks, package-cleanup is what I want:)
>
> -Ray

install the plugin: remove-with-leaves

then you can enable it when you want to remove a package and have yum 
remove anything that the pkg depends on that nothing else depends on.

-sv

[Muayyad AlSadi]

warning: leaves in package-cleanup or remove-with-leaves could be your
preferred application because it's a leaf [ie. no installed package
depends on it, eg. pidgin or uget]

there is a flag in conf of remove-with-leaves to exclude non-library
binary packages from being removed

Yum does not trace if some package is installed per user request or
pulled for dependency

[Ville Skyttä]

On Saturday 29 August 2009, Muayyad AlSadi wrote:
> warning: leaves in package-cleanup or remove-with-leaves could be your
> preferred application because it's a leaf [ie. no installed package
> depends on it, eg. pidgin or uget]

FWIW, there's also a show-leaves plugin which just lists installed packages 
that became leaves after a transaction.  Compared to remove-with-leaves, it 
doesn't remove anything, and lists new leaf packages also after install/update 
transactions in addition to erase ones.

[Ray Chen]

在 2009-08-29六的 17:32 +0300，Muayyad AlSadi写道：
> warning: leaves in package-cleanup or remove-with-leaves could be your
> preferred application because it's a leaf [ie. no installed package
> depends on it, eg. pidgin or uget]

The output of package-cleanup --leaves or remove-with-leaves doesn't
include pidgin or uget package on my F10 system.
> there is a flag in conf of remove-with-leaves to exclude non-library
> binary packages from being removed
>
> Yum does not trace if some package is installed per user request or
> pulled for dependency

yes, that's the question. seems like yum doesn't have the feature like
'isAutoRemovable' in APT. I think this feature is good for users, hope
yum developers can support this feature, or make 'package-cleanup
--leaves' and 'remove-with-leaves' plugin more stable.

Thanks,
Ray

[Axel Thimm]

On Sun, Aug 30, 2009 at 07:21:30AM +0800, Ray Chen wrote:
> 在 2009-08-29六的 17:32 +0300，Muayyad AlSadi写道：
> > warning: leaves in package-cleanup or remove-with-leaves could be your
> > preferred application because it's a leaf [ie. no installed package
> > depends on it, eg. pidgin or uget]
> > Yum does not trace if some package is installed per user request or
> > pulled for dependency
> yes, that's the question. seems like yum doesn't have the feature
> like 'isAutoRemovable' in APT. I think this feature is good for
> users, hope yum developers can support this feature, or make
> 'package-cleanup --leaves' and 'remove-with-leaves' plugin more
> stable.

I don't think apt traces whether a packages was a pulled in manually
or automatically, does it? If so where does it store that information?
And if that information were from invokations of apt-get only
(e.g. stored under /var/*/apt) then it would miss yum, yumex,
PackageKit, smart etc. interactions.

But it would be a usefull feature for yum probably requiring an origin
field in the rpmdb to remember whether the user or the system pulled
in the package.

[Jason L Tibbitts III]

> > > > > "AT" == Axel Thimm  writes:

AT> I don't think apt traces whether a packages was a pulled in manually
AT> or automatically, does it?

yum does keep track of many things in the yumdb and I think the "reason"
key is supposed to track this, but for me it seems reason is always
"user".  I think the intent is to track packages which were installed
because the user requested them directly separately from packages which
were pulled in purely because of dependencies.

- J<

[James Antill]

On Sat, 2009-08-29 at 19:06 -0500, Jason L Tibbitts III wrote:
> > > > > > "AT" == Axel Thimm  writes:
>
> AT> I don't think apt traces whether a packages was a pulled in manually
> AT> or automatically, does it?
>
> yum does keep track of many things in the yumdb and I think the "reason"
> key is supposed to track this, but for me it seems reason is always
> "user".  I think the intent is to track packages which were installed
> because the user requested them directly separately from packages which
> were pulled in purely because of dependencies.

Yes, the reason attribute in yumdb is there primarily to start on
"solving" this "problem".
 yumdb hasn't been around an entire release yet, which makes it's data
somewhat problematic (and the testing somewhat limited). Also atm. we
don't carry reason=dep across updates, so if you do "yum update" with a
new version of a package you got as a dep. that would be considered a
user install of the new package. Both of which should explain why almost
nothing has reason=dep¹.
 Atm. I have:

% yumdb search reason dep
Loaded plugins: presto
fipscheck-1.2.0-1a.fc11.x86_64
     reason = dep

...so it does work, at what it does atm.

Probably the sanest request here is that if you do:

1. yum install blah
2. <try out blah, don't like it>
3. yum remove blah

...you don't get rid of any extra stuff you got with blah, hopefully
"yum history undo" will solve that in a better way by recording what
happened at #1 and undoing it instead of trying to piece together what
might have happened at #1 after the fact.

¹ It's also true that saving 1 cent of disk space isn't at the top of my
list of things to do.

[Seth Vidal]

On Mon, 31 Aug 2009, James Antill wrote:
> ...you don't get rid of any extra stuff you got with blah, hopefully
> "yum history undo" will solve that in a better way by recording what
> happened at #1 and undoing it instead of trying to piece together what
> might have happened at #1 after the fact.

let's not go promising things like yum history undo which are not 
committed, not tested and, in the case of large update/install 
transactions, unlikely to do what the user wants.

-sv

[Axel Thimm]

On Mon, Aug 31, 2009 at 10:42:12AM -0400, James Antill wrote:
> On Sat, 2009-08-29 at 19:06 -0500, Jason L Tibbitts III wrote:
> > > > > > > "AT" == Axel Thimm  writes:
> >
> > AT> I don't think apt traces whether a packages was a pulled in manually
> > AT> or automatically, does it?
> >
> > yum does keep track of many things in the yumdb and I think the "reason"
> > key is supposed to track this, but for me it seems reason is always
> > "user".  I think the intent is to track packages which were installed
> > because the user requested them directly separately from packages which
> > were pulled in purely because of dependencies.
>
> Yes, the reason attribute in yumdb is there primarily to start on
> "solving" this "problem".

This sounds like a nice addition to yum, I hadn't heard yet of the
yumdb!

Will other frontends like PackageKit also pass down this information
to yum (e.g. which packages are user chosen, which are automatically
pulled in), so the yumdb info is universal?

[Matthew Woehlke]

James Antill wrote:
> ATM we
> don't carry reason=dep across updates

To ask the obvious... why not? An update is not necessarily a user 
action (I run 'yum upgrade -y' in cron jobs on two machines, and may 
start doing it on more).

IMO updating an existing package should *never* change the reason. 
Installing a package via update should only set reason="user" if the 
package was named in the arguments to yum (which should be the behavior 
also for 'yum install', actually).

...and I suppose 'yum update' should warn when updating a package named 
in the arguments if that package is not marked reason="user". (Why not 
auto-mark? Because maybe I am updating a library to fix a bug in some 
dependent program I use; I probably don't care about keeping that 
library if I later remove the program that needs it.)
> Probably the sanest request here is that if you do:
> yum install blah
> <try out blah, don't like it>
> yum remove blah
>
> ...you don't get rid of any extra stuff you got with blah, hopefully
> "yum history undo" will solve that in a better way by recording what
> happened at #1 and undoing it instead of trying to piece together what
> might have happened at #1 after the fact.

Actually, I disagree. Let's say I install bar, with dependencies cow and 
pig. Then I install foo with dependencies cow and dog.

What I would like to see happen is 'yum remove bar' removes bar and pig 
(but not cow, because foo needs it). If I then later 'yum remove foo', 
that should take care of foo, cow and dog.

'history undo' only works if nothing happens between the request to 
undo, and the action being undone (or else intervening actions have a 
net effect of nothing).

If reason worked correctly, I don't see a problem with 'yum remove' 
always removing dependencies when no longer needed.
> ¹ It's also true that saving 1 cent of disk space isn't at the top of my
> list of things to do.

Unneeded packages don't just use disk space, they also use CPU, network 
bandwidth, and cause excess disk wear due to the stream of updates for 
packages you don't need. (Plus that they can add up.)

And I've mentioned before that I hate this 'disk space is cheap' 
argument; it doesn't (yet) apply to SSD's and its rooted in the "make 
the user buy better hardware" attitude that IMO is a very bad thing.

[Seth Vidal]

On Wed, 2 Sep 2009, Matthew Woehlke wrote:
> James Antill wrote:
> > ATM we
> > don't carry reason=dep across updates
>
> To ask the obvious... why not?

B/c it's not been implemented, yet. The yumdb code has only really been in 
use since shortly after f11 came out.

-sv