1 |
On Thu, 14 Dec 2017 16:04:17 -0600 |
2 |
R0b0t1 <r030t1@×××××.com> wrote: |
3 |
|
4 |
> Can you be specific? Human memory is biased towards negative |
5 |
> experiences. If it's hard to actually describe the multitude of issues |
6 |
> that mixed systems cause then it is very likely mixed systems do not |
7 |
> cause many issues. |
8 |
|
9 |
We have mixed system issues in part *BECAUSE* we use keywords |
10 |
to migrate through transitions. |
11 |
|
12 |
So the expectation is that when X gets keyworded stable, that diligence |
13 |
has been performed to ensure everything else that needs to be stable at |
14 |
the same time in order to retain function, is also stabilized. |
15 |
|
16 |
Very much the case with Perl Virtuals. |
17 |
|
18 |
The design of Perl virtuals is pretty much a bodge for Portage not having |
19 |
a usable "provides" model and needing to represent certain upstream dynamics |
20 |
in ways portage can't otherwise handle. ( Due to portage being "package" based |
21 |
and upstream being "component" based ) |
22 |
|
23 |
|
24 |
And for that to work, you pretty much need to keyword virtuals, and perl, |
25 |
and sometimes perl-core/, in flying formation. |
26 |
|
27 |
And if you don't get those exposed to you in flying formation, portage gets |
28 |
very confused and tries to do silly things. |
29 |
|
30 |
( In my testing rigs I just don't bother with virtuals and have |
31 |
a >50 line package.provided file ) |
32 |
|
33 |
But that's just one example of how we use keywords in flying formation as |
34 |
a mechanism for keeping parts working. |
35 |
|
36 |
These all stem ultimately from the knowledge that other approaches |
37 |
( eg: dependdency specifications ) all end in portage getting confused in |
38 |
dependency graphs and invoking impossible stabilization requirements. |
39 |
|
40 |
Hence, keyword mixing is "discouraged if you want a stable working system". |
41 |
|
42 |
If you're advanced and responsible however, go ahead, please do, and test. |