Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 332049 - emerge: add an option to describe reason for package install (which can be recovered later by user)
Summary: emerge: add an option to describe reason for package install (which can be re...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 339092 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-10 13:45 UTC by Navid Zamani
Modified: 2010-09-29 15:10 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Navid Zamani 2010-08-10 13:45:24 UTC
This is a pretty nice idea:

You often emerge something for a specific reason (like some quick script you wrote needs is), and then forget about it.

Later your world file is cluttered with packages that you have no idea if you need them anymore.

The solution now is, to simply add another column to the world file, and allow passing a simple text string when installing something (e.g. in quotes), that gets put there. Make it the last column, and you don’t have to do any special parsing. Even “cat” and “cut” can filter it then. It’s only a tiny change to the world file reader/writer, and to the emerge command.

Semantically, the comment/reason would be seen as a “package” with a “dependency” on its package in the world file.
So when unmerging a package with “-a”, it could show the reason(s) while asking if you really want to do it.

Since the whole thing is optional, it’s 100% backwards compatible (e.g. to old scripts), as long as portage only has one interface to the world file, and isn’t spaghetti code.

As a plus, adding a option to e.g. FEATURES, that allows forcing (asking for) reasons (on merging/unmerging), would be great e.g. for professional environments where accountability is needed.

Reproducible: Always

Steps to Reproduce:
does not apply
Actual Results:  
does not apply

Expected Results:  
does not apply
Comment 1 Zac Medico gentoo-dev 2010-08-11 00:48:53 UTC
I've heard that people are using portage-2.2 usersets for something similar. Any file you create in /etc/portage/sets/ creates a new set corresponding its file name. For example, /etc/portage/sets/foo creates a set named @foo. If you `emerge @foo` then it is recorded in /var/lib/portage/world_sets. Inside /etc/portage/sets/foo, which portage does not modify, you can add as many comment lines as you want (lines starting with #).
Comment 2 Navid Zamani 2010-08-11 10:17:21 UTC
(In reply to comment #1)
> I've heard that people are using portage-2.2 usersets for something similar.

Hmm… might be a temporary workaround. But of course, creating a separate set for single packages, is a bit silly. :)
Comment 3 Zac Medico gentoo-dev 2010-08-11 10:48:49 UTC
Well, you could create one set called 'my-commented-set' and you could list as many separate atoms and comments in there as you want. So, in practice you'd only have to create one set in order to have your comment behavior.
Comment 4 Navid Zamani 2010-08-11 12:04:20 UTC
(In reply to comment #3)
And how would I unmerge a single package then?
Comment 5 Zac Medico gentoo-dev 2010-08-11 12:13:17 UTC
Well, you could just unmerge it, but you'd have to edit your set if you don't want it to be pulled in by that set anymore.
Comment 6 Navid Zamani 2010-08-11 12:29:59 UTC
(In reply to comment #5)
> Well, you could just unmerge it, but you'd have to edit your set if you don't
> want it to be pulled in by that set anymore.

I don’t call that a solution. ;)
Comment 7 SpanKY gentoo-dev 2010-08-11 16:33:11 UTC
i think what Zac is proposing is a lot more scalable than arbitrary text
Comment 8 Navid Zamani 2010-08-11 17:04:15 UTC
(In reply to comment #7)
> i think what Zac is proposing is a lot more scalable than arbitrary text

But at the cost of the very point I created this bug for: To *automate* the functionality. If I manually have to edit the set and check if I can remove it, I have gained nothing. I could just as well simply create a plain text file with the packages (and sets) mapped to descriptions, and a wrapper around emerge.

My need is a small functionality. Nothing fancy. Of course you can make it into a fancy large thing too, if you want. But not at the cost of the simple base interface I proposed.
Comment 9 Zac Medico gentoo-dev 2010-09-29 15:10:38 UTC
*** Bug 339092 has been marked as a duplicate of this bug. ***