1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
> |
3 |
> you'll still need logic like "|| ( |
4 |
> dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor )" |
5 |
> to just deal with the reality of what upstream are asking for. |
6 |
|
7 |
My point is that the perl ebuild need not necessarily follow upstream: |
8 |
It follows what the perl *ebuild* provides. |
9 |
If upstream decides to remove a package, you can just pull it |
10 |
from the ebuild (with PDEPEND, I agree) nevertheless. |
11 |
|
12 |
> If such a list of USE flags existed, it would be a very strong |
13 |
> recommendation that they *ALL* be turned on. |
14 |
|
15 |
Yes, this is why I said manually disabling is comparable with |
16 |
setting USE=minimal: for most users not recommended unless you |
17 |
really have the necessity to build a minimal system for some reason. |
18 |
So I would not care too much about occassional unnecessary recompilation |
19 |
of perl itself only for the small numbers of users having such a necessity. |
20 |
|
21 |
> And pulling in perl-core/Whatever by doing |
22 |
>=dev-lang/perl[perl_module_whatever] is just a nastier form of |
23 |
> virtual/perl-Whatever, with the limitation that you're completely |
24 |
> destroying any version support. |
25 |
|
26 |
If you need version support you still can depend on perl-core or virtual/* |
27 |
but currently there is no way to explicitly prefer the perl-provided version |
28 |
in the dependency (unless you code it manually). |
29 |
|
30 |
> Thats not really the issue, the issue is that because the modules *ARE *deemed |
31 |
> dual life by upstream, that is, it is expected that end users can depend on |
32 |
> a specific version of a module that exists in both perl itself, and as a |
33 |
> standalone, that end users *may* depend on such things and expect that to |
34 |
> work. |
35 |
|
36 |
Yes, he may depend on the explicit perl-core/* with version |
37 |
(and perhaps also some virtual/* where it is likely that such |
38 |
an explicit version is provided by perl itself - probably only |
39 |
very few): |
40 |
|
41 |
>> As mentioned above, this involves only a relatively small number of |
42 |
>> virtuals. Here is how I got the list: |
43 |
>> |
44 |
>> eix --print-all-depends | sed 's/"//g' \ |
45 |
>> grep -o '[^ ]*virtual/perl-[^ ]*-[0-9][^ ]*' |sort -u |
46 |
>> |
47 |
> I get 566 for me. |
48 |
|
49 |
different *minimal versions* but much less (IIRC 62) packages |
50 |
which is already now lower than the number of virtual/perl-*. |
51 |
Moreover, many of the minimal versions are probably meanwhile |
52 |
redundant (since the highest version is stable anyway and often |
53 |
already provided by current stable perl). |
54 |
Since most packages occur only once or twice, I guess that if the |
55 |
redundancy is eliminated you end up with only 10-20 for which a |
56 |
virtual might really make sense (or, alternatively, for which you |
57 |
must directly depend on perl-core/*, since the probability to |
58 |
just have the correct version in perl is rather low anyway). |
59 |
|
60 |
> And note, you're showing the dependencies, not the dependants. |
61 |
|
62 |
This is the point, because only this is what is interesting: |
63 |
You do not need a virtual with version number if absolutely nothing |
64 |
is using it. |
65 |
|
66 |
> If you remove the unique criteria, you get a lovely 20260 lines |
67 |
> of output! |
68 |
|
69 |
This number has no meaning. Moreover, if you should decide |
70 |
to change the way how modules depend, this is a question |
71 |
of writing a single perl-script ;) which changes the style |
72 |
in all ebuilds. I can gladly provide such a script if you want. |
73 |
|
74 |
>|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) |
75 |
> |
76 |
> That is plain wrong imo. You're prematurely optimising the dependency. |
77 |
|
78 |
The alternative is to pull in a duplicated installation which is |
79 |
completely superfluous, since it is already installed by most |
80 |
perl versions, |
81 |
|
82 |
> There is no guarantee any future version of Perl will contain it. |
83 |
|
84 |
That's why it is necessary to manually update the dependency - |
85 |
a lot more work than to depend on dev-lang/perl[Term-ANSIColor] |
86 |
and only edit a future perl ebuild to pull in the package. |
87 |
|
88 |
> The virtuals job is to invoke dependency on dev-lang/perl as much as |
89 |
> possible, and default to perl-core/* when dev-lang/perl does not provide |
90 |
> the version matched on the virtual. |
91 |
|
92 |
In this example (one of many) the version plays no role |
93 |
for the dependency, but nevertheless the virtual/... implementation |
94 |
will pull in an unnecessary package. |
95 |
|
96 |
> I'd also sooner consider attempting to eliminate the need for virtuals by |
97 |
> unilaterally depending on perl-core/* , and vivifying perl-core/ from |
98 |
> dev-lang/perl sources as needed. |
99 |
|
100 |
This breaks proper support for building/using binary packages for |
101 |
perl-core/* since the installed files will depend on which packages |
102 |
are installed at build-time. |