1 |
Rich Freeman <rich0@g.o> wrote: |
2 |
> On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth <martin@×××××.de> wrote: |
3 |
>> ...but by introducing all the additional complications Ian |
4 |
>> has mentioned. More precisely: What happens if new dependencies |
5 |
>> are introduced which are not satisfied? |
6 |
>> One has to face it: Portage must not just silently "update" the |
7 |
>> database and thus silently produce a /var/db which does not |
8 |
>> satisfy its own dependencies... |
9 |
> |
10 |
> While this is problematic, I think portage actually can handle this |
11 |
> (but I haven't tested this recently). |
12 |
|
13 |
The problem here arises if new dependencies with automatic |
14 |
subslots (foo/bar:=) are added which are not yet installed: |
15 |
Portage cannot fill these correctly. |
16 |
|
17 |
Solving all these difficulties appears harder to me than |
18 |
implementing dynamic deps correctly. |
19 |
|
20 |
> I think that allowing devs to instruct portage to update VDB with |
21 |
> USE/dep/etc changes is potentially less problematic than having |
22 |
> portage trying to guess what the right thing to do is. |
23 |
|
24 |
I completely agree. The idea of minor revisions is just one of |
25 |
several possibilities to achieve this; there are several others |
26 |
(e.g. another metadata variable describing which versions |
27 |
can be updated by skipping the prepare/config/compile/merge |
28 |
phases). The implementation, however, would be rather similar: |
29 |
Usually you need a new EAPI (or in case of noninvasive change |
30 |
might discuss whether to change EAPI's retroactively), and |
31 |
some "reemerging without the time-consuming phases" |
32 |
must be implemented. |