1 |
On Wed, Apr 8, 2015 at 3:45 AM, Martin Vaeth <martin@×××××.de> wrote: |
2 |
> Rich Freeman <rich0@g.o> wrote: |
3 |
>> |
4 |
>> Keep in mind that keeping track of past decisions made by portage does |
5 |
>> not require user-editable config files in /etc. |
6 |
> |
7 |
> Yes, but you might not always agree with portage's decisions, |
8 |
> and the resolution might be non-unique. |
9 |
|
10 |
How is this different with USE flags vs package installs? The |
11 |
satisfaction of virtuals could have many possible solutions. We make |
12 |
it deterministic by defaulting to the first option listed for the |
13 |
first package that happens to get installed. If you install a series |
14 |
of packages in various orders from a fresh install, you could get |
15 |
different packages installed to satisfy virtuals. |
16 |
|
17 |
The solution we provide for package installs is that the user can just |
18 |
emerge a dependency manually if they have a preference, and then |
19 |
portage will stick with it unless there is a conflict. |
20 |
|
21 |
For dynamic USE flags I've already proposed two mechanisms to give the |
22 |
user control: |
23 |
1. They can STILL populate /etc/portage/package.use and make explicit |
24 |
choices, which portage will follow. |
25 |
2. They could manually install a package with one-time specified USE |
26 |
flags, and portage would stick with these as long as they don't create |
27 |
a conflict. |
28 |
|
29 |
Why do we need another mechanism to control what flags a package gets |
30 |
installed with other than these two, such as making more detailed |
31 |
cache data user-editable? |
32 |
|
33 |
-- |
34 |
Rich |