| Summary: | GLEP 21 ( User Sets ) | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Tom Ribbens <webmaster> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | arfrever, dev, lionel_sanchez, matej, rhill, wes, witr |
| Priority: | High | ||
| Version: | 2.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 144480, 423075 | ||
| Attachments: |
against svn
Patch against svn, round two Fix a bug in the System set, also squelch some complaining about missing atoms in porttree by checking for them in the vdb. |
||
|
Description
Tom Ribbens
2002-08-13 08:36:17 UTC
I just wanted to request this feature and found this entry. So indeed this would be a tremendously useful feature.Having a dir where you can put your files having a simple format (package name per line??) then you could emerge -u -p --category mydevel and it would say you need distcc, cvs, valgrind and gdb upgraded. The most upsetting thing now is having to grep the huge list of world updates if I only want some specific tool and don't care about all the others. I also like the idea of user defined package-sets. *** Bug 89052 has been marked as a duplicate of this bug. *** Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) *** Bug 100649 has been marked as a duplicate of this bug. *** patch Created attachment 94659 [details, diff]
against svn
no unmerging yet.
That patch is incomplete, or where is portage_sets.py? Also don't really like the existing part of it, sets shouldn't require a special option and system/world should IMO be implemented as sets right from the start. (In reply to comment #9) > That patch is incomplete, or where is portage_sets.py? > Also don't really like the existing part of it, sets shouldn't require a > special option and system/world should IMO be implemented as sets right from > the start. > Ahh yes it was very early :P I will post a new one soon with portage_sets.py soon ;) Sets requiring a special option is necessary imho, otherwise you incure an annoying amount of processing to figure out that items in myfiles are actually a set; you need to do this to set the proper options in depgraph. Also mixing sets and normal packages is bad idea (for similar depgraph related reasons). System and world are already sets, although I plan to unify SetCreate and xCreate, mostly I was trying not to break the existing functionality with this first try. Created attachment 96849 [details, diff]
Patch against svn, round two
Ok, this should be a bit better (and complete). Out of the box it should support ["world","system","all"] sets as well as anything you place in /etc/portage/sets/
emerge <setname1> <setname2> should work fine
There is one place where it bitches about unavailable atoms; I need to fix that still.
Created attachment 96851 [details, diff]
Fix a bug in the System set, also squelch some complaining about missing atoms in porttree by checking for them in the vdb.
Ok apparently you people want backend support (via dbapi); I'll cut myself and then get to work on a patch. *** Bug 154753 has been marked as a duplicate of this bug. *** (In reply to comment #14) > *** Bug 154753 has been marked as a duplicate of this bug. *** > Just to add; when I made 154753 (without noticing this bug); one of the suggestions was to have basic set operations; so that you could do something like world \minus system, and things like that. Also, it would be convenient to type out sets from their elements on the command line; like world \minus {openoffice}. Just some thoughts... -wes *** Bug 158215 has been marked as a duplicate of this bug. *** (In reply to comment #16) > *** Bug 158215 has been marked as a duplicate of this bug. *** > That was me. I searched! Honest. Anyway, as it says, there needs to be a "toolchain" argument that gets used when updating the compiler, otherwise when you use "system" you get to build 300 things, 90% of which are not toolchain. Then you rebuild them all when you do a "emerge -eav world". I think this should be a standard item. it's easy enough to just do `emerge -av glibc binutils gcc`, but i guess it might be useful if it's easy enough to do. do any of the alt arches have different toolchains? *** Bug 204493 has been marked as a duplicate of this bug. *** *** Bug 206528 has been marked as a duplicate of this bug. *** This is implemented in portage-2.2 (lacks a bit on the documentation front though). |
