1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> |
3 |
>> this dependency will install for a user with unstable keywords |
4 |
>> |
5 |
> |
6 |
> That, in itself, indicates the user is usually OK with "new versions of |
7 |
> things" ;) |
8 |
|
9 |
You are intentionally confusing "new version" (AKA upgrade) with |
10 |
_additional_ installation of a package, just because that package |
11 |
contains a newer version. |
12 |
|
13 |
If you explicitly installed that package, an upgrade of course |
14 |
is desired, but *hard depending* on a package just because it |
15 |
provides a newer version of a bundled package is more than |
16 |
questionable: |
17 |
|
18 |
Would you think that it is correct if e.g. a multimedia package |
19 |
which *forcibly* has bundled ffmpeg should in addition *forcibly* |
20 |
depend on the system ffmpeg library (for no other reason than |
21 |
it is bundled anyway)? According to your definition of |
22 |
"always guarantee to install new version" this would have to |
23 |
be the case. |
24 |
|
25 |
I agree that no solution is completely satisfactory: |
26 |
The most correct solution might be to unbundle the library - |
27 |
which for perl would mean to *not* install the provided |
28 |
modules but put all of them in perl-core. But as often, |
29 |
unbundling is here a *very* hard job (how to solve the |
30 |
chicken-and-egg problem of installing perl packages |
31 |
without having packages available for installation) |
32 |
and probably manpower is missing to do this for every |
33 |
perl version... |
34 |
|
35 |
But in fact, this solution would allow complete |
36 |
elimination of all artificial workarounds by |
37 |
virtuals, eclasses or USE-flags and circumvent the problem |
38 |
of duplicate installation of packages completely. |