1 |
On 28 September 2013 22:46, Martin Vaeth |
2 |
<vaeth@××××××××××××××××××××××××.de>wrote: |
3 |
|
4 |
> Kent Fredric <kentfredric@×××××.com> wrote: |
5 |
> > |
6 |
> > you'll still need logic like "|| ( |
7 |
> > dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor |
8 |
> )" |
9 |
> > to just deal with the reality of what upstream are asking for. |
10 |
> |
11 |
> My point is that the perl ebuild need not necessarily follow upstream: |
12 |
> It follows what the perl *ebuild* provides. |
13 |
> If upstream decides to remove a package, you can just pull it |
14 |
> from the ebuild (with PDEPEND, I agree) nevertheless. |
15 |
> |
16 |
> |
17 |
So are you basically suggesting that for dual life modules, we simply |
18 |
ignore that they're dual-lifeable, and then when upstream splits a package |
19 |
from core so that its no longer dual life, that we simply ignore that too, |
20 |
and fake it still being core for the forseeable future? |
21 |
|
22 |
|
23 |
> If such a list of USE flags existed, it would be a very strong |
24 |
> > recommendation that they *ALL* be turned on. |
25 |
> |
26 |
> Yes, this is why I said manually disabling is comparable with |
27 |
> setting USE=minimal: for most users not recommended unless you |
28 |
> really have the necessity to build a minimal system for some reason. |
29 |
> So I would not care too much about occassional unnecessary recompilation |
30 |
> of perl itself only for the small numbers of users having such a necessity. |
31 |
> |
32 |
> |
33 |
IMO, really, the uses would be forced enabled for all users, because they |
34 |
should never be disabled. If they're part of the Perl built itself, they |
35 |
should get installed. Period. |
36 |
|
37 |
Then by forcing them on all the time, you can use them how you were |
38 |
initially suggesting, as a way to track interdependencies between versions |
39 |
of perl ( ie: When perl itself stops being able to provide something, the |
40 |
USE flag goes away ... but thats messy as hell, and an abuse of the entire |
41 |
purpose of USE flags, to control features, not to simply track properties |
42 |
of a package for the purpose of cross dependencies ) |
43 |
|
44 |
For that, a slot-dict approach is far more sane. |
45 |
|
46 |
|
47 |
> > And pulling in perl-core/Whatever by doing |
48 |
> >=dev-lang/perl[perl_module_whatever] is just a nastier form of |
49 |
> > virtual/perl-Whatever, with the limitation that you're completely |
50 |
> > destroying any version support. |
51 |
> |
52 |
> If you need version support you still can depend on perl-core or virtual/* |
53 |
> but currently there is no way to explicitly prefer the perl-provided |
54 |
> version |
55 |
> in the dependency (unless you code it manually). |
56 |
> |
57 |
> |
58 |
But why would you "depend on the perl-provided version" , that mentality is |
59 |
nowhere upstream, and nowhere downstream. |
60 |
|
61 |
Are you saying that, if something is provided by perl core, that we must |
62 |
never update to a cpan version? |
63 |
|
64 |
You realise thats breaking how upstream thinks toolchains work right? |
65 |
|
66 |
Because even CPAN and friends like that will upgrade things in core to |
67 |
their cpan versions where possible. |
68 |
|
69 |
There is *no* way for upstream to declare "I want whatever version of X is |
70 |
in your current perl", they can only state "I want X" or fail to state they |
71 |
want X, and assume toolchain does the right thing. Even then, that will |
72 |
result in tools using more recent versions of things from CPAN. |
73 |
|
74 |
> Thats not really the issue, the issue is that because the modules *ARE |
75 |
> *deemed |
76 |
> > dual life by upstream, that is, it is expected that end users can depend |
77 |
> on |
78 |
> > a specific version of a module that exists in both perl itself, and as a |
79 |
> > standalone, that end users *may* depend on such things and expect that to |
80 |
> > work. |
81 |
> |
82 |
> Yes, he may depend on the explicit perl-core/* with version |
83 |
> (and perhaps also some virtual/* where it is likely that such |
84 |
> an explicit version is provided by perl itself - probably only |
85 |
> very few): |
86 |
> |
87 |
|
88 |
But that raises a problem, because some versions that end users may depend |
89 |
on are *NOT* available as perl-core/* , they are only available in a |
90 |
specific incarnation of Perl. |
91 |
|
92 |
Or sometimes, a version will appear on CPAN, and people will start |
93 |
depending on it ( requiring you to invoke a perl-core/* dependency ), and |
94 |
later, that version will be shipped in perl itself, resulting in the need |
95 |
to retroactively modify every ebuild that depended on perl-core/* of those |
96 |
versions to use the perl one instead. |
97 |
|
98 |
Because otherwise, you'll have end users complaining they have to install |
99 |
perl-core/Term-ANSIColor-4.20.0 when they're using 5.18.0, which comes with |
100 |
that version anyway. |
101 |
|
102 |
|
103 |
> > And note, you're showing the dependencies, not the dependants. |
104 |
> |
105 |
> This is the point, because only this is what is interesting: |
106 |
> You do not need a virtual with version number if absolutely nothing |
107 |
> is using it. |
108 |
> |
109 |
> > If you remove the unique criteria, you get a lovely 20260 lines |
110 |
> > of output! |
111 |
> |
112 |
> This number has no meaning. Moreover, if you should decide |
113 |
> to change the way how modules depend, this is a question |
114 |
> of writing a single perl-script ;) which changes the style |
115 |
> in all ebuilds. I can gladly provide such a script if you want. |
116 |
> |
117 |
> |
118 |
You're missing a very important point: Every single line of output without |
119 |
the uniq constraint is a package depending on a virtual. |
120 |
|
121 |
The virtual is managing the need to have a conditional dependency based on |
122 |
the version of perl installed. |
123 |
|
124 |
You would need to ,without virtuals, modify *EVERY* ebuild containg a |
125 |
dependency on a virtual, to contain the respective conditional dependency |
126 |
enshrined in the virtual. |
127 |
|
128 |
Not only that, instead of what we currently do, modify the indivual |
129 |
virtuals to adapt to new perl releases, with the conditional codified in |
130 |
the .ebuild, you would need to modify *EVERY* ebuild that had such a |
131 |
dependency after *EVERY* perl release. |
132 |
|
133 |
Not sure about you, but the idea of modifying 20,000 lines of code instead |
134 |
of 1, is something I don't look on fondly. |
135 |
|
136 |
>|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) |
137 |
> > |
138 |
> > That is plain wrong imo. You're prematurely optimising the dependency. |
139 |
> |
140 |
> The alternative is to pull in a duplicated installation which is |
141 |
> completely superfluous, since it is already installed by most |
142 |
> perl versions, |
143 |
> |
144 |
|
145 |
You're not though. Thats the point. Virtuals are doing exactly that. |
146 |
They're just doing it in the virtual instead of your ebuild. |
147 |
|
148 |
If you are installing virtual Y version X, if you are on a version of Perl |
149 |
that contains Y version X, the virtual avoids the need to install the |
150 |
respective perl-core/X. |
151 |
|
152 |
Thats exactly how they work, and is exactly their point. |
153 |
|
154 |
If you want proof of this: |
155 |
|
156 |
eix --only-names -IcC virtual | grep 'virtual/perl-' | wc -l |
157 |
50 |
158 |
|
159 |
eix --only-names -IcC perl-core | wc -l |
160 |
35 |
161 |
|
162 |
So thats 15 virtuals that are still not pulling in any superflous |
163 |
perl-core/* |
164 |
|
165 |
They don't need to, they've short-circuited to using perl instead. |
166 |
|
167 |
If you don't like that packages get updated, and pull newer-that-core |
168 |
versions of things, there's nothing to stop you grepping virtual/perl-*, |
169 |
and masking versions that don't match an "=your current version of perl". |
170 |
|
171 |
And then it will cease to pull in *any* perl-core/* |
172 |
|
173 |
Lots of things will not work if you do that, but you can do that. |
174 |
|
175 |
Sure, the perl-core/ family will be around for a little longer, but they |
176 |
should become candidates for depcleaning as soon as the conditionals |
177 |
default to perl. |
178 |
|
179 |
You could also mask perl-core/* and see what that does, though I'd wager |
180 |
you'll see a lot of things breaking. |
181 |
|
182 |
In this example (one of many) the version plays no role |
183 |
> for the dependency, but nevertheless the virtual/... implementation |
184 |
> will pull in an unnecessary package. |
185 |
> |
186 |
> |
187 |
As stated above, if your objection is simply getting new versions of things |
188 |
in core needlessly, be my guest, disable that mechanic. You can do so right |
189 |
now. Though I'd advise against it, because that mechanic is nessecary for |
190 |
many things, hence, why we have it. |
191 |
|
192 |
> I'd also sooner consider attempting to eliminate the need for virtuals by |
193 |
> > unilaterally depending on perl-core/* , and vivifying perl-core/ from |
194 |
> > dev-lang/perl sources as needed. |
195 |
> |
196 |
> This breaks proper support for building/using binary packages for |
197 |
> perl-core/* since the installed files will depend on which packages |
198 |
> are installed at build-time. |
199 |
|
200 |
|
201 |
I'm not really sure what you're sayng here. Sorry :/ |
202 |
|
203 |
|
204 |
-- |
205 |
Kent |