Summary: | emerge: add an option to describe reason for package install (which can be recovered later by user) | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Navid Zamani <navid.zamani> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | bug |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Navid Zamani
2010-08-10 13:45:24 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 #). (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. :) 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. (In reply to comment #3) And how would I unmerge a single package then? 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. (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. ;) i think what Zac is proposing is a lot more scalable than arbitrary text (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. *** Bug 339092 has been marked as a duplicate of this bug. *** |