Bug 141226 – emerge --depclean improvement

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description David Carlos Manuelda 2006-07-20 18:29:55 UTC]

I have an idea to have an never failing and never deleting packages wich never had to be deleted idea for depclean option. Here it goes.

The idea is to have a little database similar to world, but including in every emerge wich package requested some other package, and deleting that package from DB when unmerging the original. This way it can be obtained in the database why were installed some packages. For example, emerging apache, it needs (with my actual world): dev-libs/apr-0.9.12, dev-libs/apr-util-0.9.12, app-misc/mime-types-5, net-www/apache-2.0.58.

This idea would have (partial) database like this:

Package                               Requested By
dev-libs/apr-0.9.12                     apache, apr-util
dev-libs/apr-util-0.9.12                apache
app-misc/mime-types-5                   apache
net-www/apache-2.0.58                   direct /* Emerged because the user wanted to */


If, past a year for example, I merged more things and store this info in database, I could have a DB like this:

dev-libs/apr-0.9.12                     apr-util
dev-libs/apr-util-0.9.12                none
app-misc/mime-types-5                   none
net-www/apache-2.0.58                   direct /* Emerged because the user wanted to */

So every none is a *real* none required and could remove theoretically safely from system.

I don't know how this idea is, but I only would like to help aou a little :)

[Comment 1 Zac Medico 2006-07-21 16:33:10 UTC]

The dependency data is already stored in /var/db/pkg/*/*/*DEPEND.  Is this a duplicate of bug 41417 ?

[Comment 2 David Carlos Manuelda 2006-07-21 19:01:04 UTC]

I didn't want to say the dependency data /var/db/pkg/*/*/*DEPEND BEFORE compiling, I was saying to store that dependency data AFTER merging software, and that way, when certain time has passed (merging and unmerging some apps) you will know accurately *why* all the packages were installed and *what* program required it.

It is completely different to storing DEPEND data in an ebuild to has all its dependencies ready in compile time.

Maybe I explained it wrong. Is it clear now what I wanted to say?

[Comment 3 Marius Mauch (RETIRED) 2006-07-22 08:57:56 UTC]

I don't understand what you're trying to say.
"It is completely different to storing DEPEND data in an ebuild to has all its
dependencies ready in compile time." <- doesn't make any sense to me.

[Comment 4 David Carlos Manuelda 2006-07-22 09:21:51 UTC]

I was trying to say that DEPEND stores the dependency tree for compiling purposes (avoiding compilations fails, enable/disable features, etc..). But what I was trying to expose is to keep track of all packets, and *WHY* were them installed (what application(s) required it). This way, you can now why were installed certain packets before attempting to remove them.
For example, with libqt(32 bits emulated)(I forgot name of ebuild): much apps require it, but system changes as time goes by, so I can easyly forget what app requested this libs, it would be unsafe to simply remove from system, 'cause there could be some apps wich are still using it. With this idea, this can be avoided 'cause the record of wich package makes install of another (as dependency) is keps for all packages. Is it More clear now? (sorry, I cannot explain better in english :) )

[Comment 5 Marius Mauch (RETIRED) 2006-07-22 11:49:05 UTC]

I still don't see the difference between storing RDEPEND="foo" in bars vdb entry and storing "package foo requested by bar" in your suggested system. The info is the same, you just seem to express it differently.
If you can give me an *actual* example where the dep info that's currently stored in vdb is inadequate.

[Comment 6 Zac Medico 2006-07-25 19:54:41 UTC]

*** This bug has been marked as a duplicate of 41417 ***