>> and I'd assume users might get rather confused to answer questions >> that are then thrown away later. > I don't unterstand what do you mean by that... >
It's a chicken and egg problem. Portage's job is to examine your systems configuration (key here is USE flags) and the calculate dependences based on those flags (among other things). So in order for your idea to work with 1 round of dependency resolution; emerge basically needs a backtracking dependency resolver. Take the following use case for example. new-awesome-emerge foo foo has 3 use flags, [bar,-baz,-snuffles], bar is enabled by your existing configuration. Do you wish to enable baz? (Y/N): Y Do you wish to enable snuffles? (Y/N): Y * At this point because you have changed USE flags you have invalidated the previous dependency graph (new USE flags enabled means new deps might get pulled in or excluded). So every time someone adds (or removes) a flag you need to recalculate deps or your dependency tree will be wrong. This whole issue can be solved by adding or removing flags from /etc/portage/package.use instead of /etc/make.conf However this leads us into the next point. >> Another (relatively minor) problem >> is that the flags set in such a session would have to be made >> persistent somehow, and I wouldn't want emerge to mess >> with /etc/portage/package.* files > Why ? it's just doing something the user will normally do.... > It's been a long standing policy not to touch user configuration. I can think of only 1 instance when we currently do it and thats when we process updates/ and notice a package move; we have to rename that CP in all configurations so the user doesn't get their system in a weird state. The problem with editing stuff like this is usually that when users and machines edit the same file; bad things happen. It is hard for the machine to know what the user is doing in there; and vice versa. >> As for listing USE flag descriptions, there are already >> patches floating around for that (at least TGL wrote one a while >> ago), and even if not it would be hardly worth a complete SoC project >> by itself. > My idea was to integrate this with emerge, and this seemed something > not very easy. But I totally agree that it's very easy (too for the SoC) > to make an external tool to do that. So, since you think that emerge is > not a place for that, I'll search for a new idea for the SoC and try to > make this simple tool next week ;) Emerge is a big piece of shit (honestly) and it does way too much already, no need to add more stuff to it, imho. The biggest problem you will encounter is that adding and removing use flags is an interative process. -Alec -- [email protected] mailing list
