1 |
Kent Fredric <kentfredric@×××××.com> wrote: |
2 |
>> |
3 |
> So are you basically suggesting that for dual life modules, we simply |
4 |
> ignore that they're dual-lifeable, and then when upstream splits a package |
5 |
> from core so that its no longer dual life, that we simply ignore that too, |
6 |
> and fake it still being core for the forseeable future? |
7 |
|
8 |
Yes, this is the idea. |
9 |
|
10 |
(Although I must admit that meanwhile I prefer the ebuild idea). |
11 |
|
12 |
> IMO, really, the uses would be forced enabled for all users, because they |
13 |
> should never be disabled. If they're part of the Perl built itself, they |
14 |
> should get installed. Period. |
15 |
|
16 |
Exactly: Those which are part of the Perl built itself would not have a |
17 |
useflag at all. Only for those which are *not* in part of the current |
18 |
perl built you would have a useflag. For instance, |
19 |
USE=Time-Piece would not occur in the perl-5.10* ebuilds but in all |
20 |
other perl ebuilds in the form |
21 |
PDEPEND="Time-Piece? ( perl-core/Time-Piece )" |
22 |
|
23 |
Packages needing Time-Piece would then just |
24 |
RDEPEND="dev-lang/perl[Time-Piece(+)]" |
25 |
and would thus implicitly get the correct dependency. |
26 |
|
27 |
Once the translation is done, the only place where maintenance is needed |
28 |
are the perl-ebuilds. |
29 |
|
30 |
> But why would you "depend on the perl-provided version" |
31 |
|
32 |
Many packages only need the basic functionality of a library, |
33 |
not a particular version. The problem is that something like |
34 |
|
35 |
RDEPEND="virtual/perl-..." |
36 |
|
37 |
implicitly depends on a particular version, namely the highest |
38 |
one which is currently stable/unstable for your architecture |
39 |
instead of the one which avoids unnecessary installation. |
40 |
|
41 |
> Are you saying that, if something is provided by perl core, that we must |
42 |
> never update to a cpan version? |
43 |
|
44 |
If the user explicitly requires a particular package or |
45 |
if a package explicitly depends on a certain minimal version, |
46 |
the upgrade will be automatic. |
47 |
However, if there is no need (dependency or explicit user request) |
48 |
for a particular version, the installed version should be sufficient. |
49 |
|
50 |
> You realise thats breaking how upstream thinks toolchains work right? |
51 |
|
52 |
Upstream always thinks that you have to use the most current |
53 |
unstable version of everything. This is not only true for perl |
54 |
but also for every other bigger project (texlive or many others |
55 |
come to mind). It is the distribution's task to give a more |
56 |
stable user experience. |
57 |
|
58 |
> You're missing a very important point: Every single line of output without |
59 |
> the uniq constraint is a package depending on a virtual. |
60 |
|
61 |
This is not the case, but this need not be discussed here; |
62 |
we agree that the number of *packages* depending on |
63 |
virtual versions is large. |
64 |
|
65 |
> The virtual is managing the need to have a conditional dependency based on |
66 |
> the version of perl installed. |
67 |
> |
68 |
> You would need to ,without virtuals, modify *EVERY* ebuild containg a |
69 |
> dependency on a virtual, to contain the respective conditional dependency |
70 |
> enshrined in the virtual. |
71 |
|
72 |
No. You just keep those few virtuals for which the packages explicitly |
73 |
depend on the version. The remaining ones - for which the version |
74 |
plays no role - are replaced *once* by the corresponding USE-dependency. |
75 |
|
76 |
(However, as said above, I meanwhile prefer the eclass idea; |
77 |
with the eclass you could treat both cases - those depending on |
78 |
a particular version and those depending only on *some* version - in the |
79 |
same way and even omit all virtuals.) |
80 |
|
81 |
> Not sure about you, but the idea of modifying 20,000 lines of code instead |
82 |
> of 1, is something I don't look on fondly. |
83 |
|
84 |
Both solutions would require only *once* to modify the dependencies. |
85 |
After the transfer is done, you only have to modify 1 line |
86 |
|
87 |
>>|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) |
88 |
>> > |
89 |
>> > That is plain wrong imo. You're prematurely optimising the dependency. |
90 |
>> |
91 |
>> The alternative is to pull in a duplicated installation which is |
92 |
>> completely superfluous, since it is already installed by most |
93 |
>> perl versions, |
94 |
> |
95 |
> You're not though. Thats the point. Virtuals are doing exactly that. |
96 |
> They're just doing it in the virtual instead of your ebuild. |
97 |
|
98 |
Only if there would be only *one* version of the corresponding |
99 |
virtual. With *more* virtual versions as it is currently, |
100 |
it is rather likely that an unneeded version of |
101 |
perl-core/Term-ANSIColor is pulled it. |
102 |
|
103 |
> If you are installing virtual Y version X, if you are on a version of Perl |
104 |
> that contains Y version X, the virtual avoids the need to install the |
105 |
> respective perl-core/X. |
106 |
|
107 |
But if I am just installing virtual Y, version does not matter, |
108 |
I will likely get virtual Y, versions X+Z although version X |
109 |
is already there and thus version Z would not be needed. |
110 |
|
111 |
> If you don't like that packages get updated, and pull newer-that-core |
112 |
> versions of things, there's nothing to stop you grepping virtual/perl-*, |
113 |
> and masking versions that don't match an "=your current version of perl". |
114 |
|
115 |
This is a lazy excuse: Instead of producing proper dependencies |
116 |
you are shifting the work to the user. |
117 |
In fact, I did this work in the beginning, but not only is this a |
118 |
lot of work for every perl upgrade (which is not so trivial to script), |
119 |
you also need a lot of exceptions where the mask is not possible, |
120 |
because some package needs a newer version. |
121 |
For e.g. overlays which I provide to users, I do not want to |
122 |
shift *my* work on the user's side and thus have to write clumsy |
123 |
dependencies without virtual/... |
124 |
|
125 |
If you use the ebuild or USE-idea you would get correct dependencies |
126 |
which do not require the user to hack around and mask things only |
127 |
to avoid unnecessary installations. |
128 |
|
129 |
>> I'd also sooner consider attempting to eliminate the need for virtuals by |
130 |
>> > unilaterally depending on perl-core/* , and vivifying perl-core/ from |
131 |
>> > dev-lang/perl sources as needed. |
132 |
>> |
133 |
>> This breaks proper support for building/using binary packages for |
134 |
>> perl-core/* since the installed files will depend on which packages |
135 |
>> are installed at build-time. |
136 |
> |
137 |
> I'm not really sure what you're sayng here. Sorry :/ |
138 |
|
139 |
If you are writing an ebuild X whose action of src_install() depends |
140 |
implicitly on the installed perl-version and the user executes |
141 |
emerge --buildpkg=y X |
142 |
on one machine and |
143 |
emerge --usepkg X |
144 |
on another machine (or at a later time) he will run into problems |
145 |
without a warning if the perl versions of that two machines are not |
146 |
the same (or have changed meanwhile) when the two commands are |
147 |
executed. |
148 |
Roughly speaking, you build an implicit dependency into the |
149 |
*.tbz2 file which portage is not aware of and will not warn |
150 |
the users about. |