Re: [gentoo-portage-dev] [SoC] Idea for emerge

[Alec Warner]

>> 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


-- 
gentoo-portage-dev@g.o mailing list