1 |
On 28 September 2013 07:48, Martin Vaeth |
2 |
<vaeth@××××××××××××××××××××××××.de>wrote: |
3 |
|
4 |
> Sorry if this is duplicate: I repost since I cannot see it after |
5 |
> a few hours. |
6 |
> |
7 |
> Kent Fredric <kentfredric@×××××.com> wrote: |
8 |
> > |
9 |
> > On 27 September 2013 08:02, Martin Vaeth |
10 |
> ><vaeth@××××××××××××××××××××××××.de>wrote: |
11 |
> > |
12 |
> >> For those which are provided by perl itself, you could have |
13 |
> >> a corresponding useflag of dev-lang/perl and make a use dependency: |
14 |
> >> If the main perl tarball does not provide the package, the perl ebuild |
15 |
> >> can pull in the corresponding package as a dependency. |
16 |
> > |
17 |
> > That would be horrible. You'd have a massive list of USE flags, and you'd |
18 |
> > want *all* of them by default, and they'd have to pull the deps as |
19 |
> > PDEPENDS, because its impossible to have them as DEPENDS. |
20 |
> |
21 |
> Why is this horrible? Perhaps there is a misunderstanding. |
22 |
> You would need only those useflags which are possibly not provided |
23 |
> by the corresponding perl version: The package dependent on a feature |
24 |
> could just use e.g. DEPEND=dev-lang/perl[perl_module_Term_ANSIColor(+)] |
25 |
> And concerning the number of use-flags, it might be worth thinking |
26 |
> about a USE_EXPAND="perl_module". |
27 |
> |
28 |
> |
29 |
Its just a "Perl module" here can be only "1 file", and worse, you'll have |
30 |
to mentally make sure the USE flags have the right interdependencies for |
31 |
USE flags that require other USE flags to work. |
32 |
|
33 |
And rebuilding all of perl to change the presence of one file, gives us a |
34 |
lot of cost, and no benefit. And it still has the problem if a user wants a |
35 |
version of something that we don't know where its going to come from for |
36 |
all time, ie: you'll still need logic like "|| ( |
37 |
dev-lang/perl[perl_module_Term_ANSIColor(-)] perl-core/Term-ANSIColor )" |
38 |
to just deal with the reality of what upstream are asking for. |
39 |
|
40 |
This solution is presently worse than virtuals, because it requires every |
41 |
ebuild to be aware of the mess of how resolving "dual life" dependencies |
42 |
work. |
43 |
|
44 |
> so maybe rebuild the entirety of Perl, just to install one thing that |
45 |
> > can be installed seperately from Perl. |
46 |
> |
47 |
> If the common flags are enabled by default, this would only involve |
48 |
> users who have a serious reason (e.g. space issues) to disable some |
49 |
> modules. Yes, these users would have to rebuild unnecessarily if |
50 |
> they change their mind later on. I would compare disabling these |
51 |
> modules with something like setting USE=minimal for other packages; |
52 |
> users should know what they are doing if they use this. |
53 |
> |
54 |
|
55 |
The problem there is you're breaking upstream, because you're breaking how |
56 |
upstream perceives perl to work. |
57 |
|
58 |
If such a list of USE flags existed, it would be a very strong |
59 |
recommendation that they *ALL* be turned on. And again, this essentially |
60 |
says "modules that are dual lifed are pretended not to be so", unless you |
61 |
combine this approach with PDEPEND |
62 |
|
63 |
And pulling in perl-core/Whatever by doing |
64 |
=dev-lang/perl[perl_module_whatever] is just a nastier form of |
65 |
virtual/perl-Whatever, with the limitation that you're completely |
66 |
destroying any version support. |
67 |
|
68 |
> Also, instead of having the logical thing when Module::Build does get |
69 |
> fully |
70 |
> > removed from perl, that we can simply remap the virtual to always pull |
71 |
> from |
72 |
> > perl-core/Module-Build, we'd have to re-write every package in tree that |
73 |
> > used Module-Build. |
74 |
> |
75 |
> My idea is to keep this in the perl ebuilds "forever": |
76 |
> According to the perlversions which are still in the tree, it will take |
77 |
> dozens of years until all perl versions providing Module-Build have |
78 |
> vanished |
79 |
> from the tree, and only afterwards it makes sense to think about |
80 |
> such a change. |
81 |
> |
82 |
> > This is a problem with Module::Build, Test-Simple |
83 |
> > and ExtUtils::MakeMaker, because people regularly depend on specific |
84 |
> > versions of those things |
85 |
> |
86 |
> My suggestion was explicitly about modules for which ebuilds do |
87 |
> not require an explicit version. For those few(!) modules for which |
88 |
> particular versions are needed, perhaps the virtual might be kept. |
89 |
> Alternatively, for such cases it might make sense to depend |
90 |
> directly on the package, since the probability to save duplicate |
91 |
> installation in such a case is rather low, anyway |
92 |
|
93 |
|
94 |
Thats not really the issue, the issue is that because the modules *ARE *deemed |
95 |
dual life by upstream, that is, it is expected that end users can depend on |
96 |
a specific version of a module that exists in both perl itself, and as a |
97 |
standalone, that end users *may* depend on such things and expect that to |
98 |
work. |
99 |
|
100 |
In the event new modules do hit tree need something that is dual lifed, it |
101 |
is much less effort to add a virtual to the tree to communicate the |
102 |
dependency properly, much less effort than rehashing dev-lang/perl itself, |
103 |
adding a new USE flag, and causing a domino of recompiles to deploy a |
104 |
hand-full of files that may not even need compiling to work. |
105 |
|
106 |
|
107 |
> > Worse than that I'm afraid, things that are virtualled are virtualled |
108 |
> > because upstream can and will depend on a specific version of that thing |
109 |
> |
110 |
> As mentioned above, this involves only a relatively small number of |
111 |
> virtuals. Here is how I got the list: |
112 |
> |
113 |
> eix --print-all-depends | sed 's/"//g' \ |
114 |
> grep -o '[^ ]*virtual/perl-[^ ]*-[0-9][^ ]*' |sort -u |
115 |
> |
116 |
> |
117 |
I get 566 for me. Thats a bit longer =) . And note, you're showing the |
118 |
dependencies, not the dependants. |
119 |
|
120 |
If you remove the unique criteria, you get a lovely 20260 lines of output! |
121 |
|
122 |
And I guess that in this list of (for the main tree, but even with |
123 |
> eix -Z ... the list is hardly longer) 62 packages |
124 |
> actually many fall into the class where the minimal version is |
125 |
> provided by current stable perl version anyway so that actually the |
126 |
> minimal version dependency is redundant. |
127 |
> |
128 |
> > And more, there is the growing list of modules that may be presently |
129 |
> > installed with perl, but are slated to stop being shipped with perl |
130 |
> > [...] and inlining a big list of |
131 |
> > conditional dependencies in each and every module that uses such a |
132 |
> package. |
133 |
> |
134 |
> I was not suggesting inlining the list into the dependency but |
135 |
> only inlining the USE-flag into the (single) perl ebuild. |
136 |
> Currently if I have a package which needs e.g. Term-ANSI-Color, |
137 |
> but not in a particular version, if I do not want to install an |
138 |
> unnecessary duplicate version, I must inline a dependency like |
139 |
> || ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) |
140 |
> and possibly change this if perl-5.20 does no longer contain |
141 |
> perl-Term-ANSIColor. |
142 |
> |
143 |
> |
144 |
> |
145 |
|| ( >=dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) |
146 |
|
147 |
That is plain wrong imo. You're prematurely optimising the dependency. |
148 |
There is no guarantee any future version of Perl will contain it. That is |
149 |
*why* we have the virtual. |
150 |
|
151 |
The virtuals job is to invoke dependency on dev-lang/perl as much as |
152 |
possible, and default to perl-core/* when dev-lang/perl does not provide |
153 |
the version matched on the virtual. |
154 |
|
155 |
This may not be important for *your* dist, but it is very necessary for |
156 |
other things. Especially in the case of blocking versions. |
157 |
|
158 |
I mean, the reason virtuals suck is predominantly the fact we have to |
159 |
update the conditionals to accurately reflect the version on the virtual, |
160 |
so that virtuals pull in perl-core/* if the version in dev-lang/perl |
161 |
doesn't match the version. |
162 |
|
163 |
Literally, the logical replacement for that is inlining that conditional in |
164 |
every .ebuild that needs it. |
165 |
|
166 |
We could, at very best, step around the problem by having an eclass that |
167 |
translates a special variable, say, |
168 |
PERL_MODULE_COREDEPS="Term::ANSIColor@3.2" or something, and that then |
169 |
translates those dependencies into the relevant switches. And that is |
170 |
something I really want to avoid, mostly, because the massive amount of |
171 |
moving parts required to implement such a feature. |
172 |
|
173 |
I'd sooner opt for a way to represent the ebuild as a template, and then |
174 |
have a process that generates ebuilds from the ebuild templates, |
175 |
automatically -r bumping things as it found dependency changes. |
176 |
|
177 |
At least that way, I wouldn't be limited to nasty arcane bash tricks that |
178 |
could explode on a user with relative ease. |
179 |
|
180 |
I'd also sooner consider attempting to eliminate the need for virtuals by |
181 |
unilaterally depending on perl-core/* , and vivifying perl-core/ from |
182 |
dev-lang/perl sources as needed. Just the maint overhead for that is |
183 |
slightly high, and entirely unsupported by upstream. |
184 |
|
185 |
|
186 |
|
187 |
|
188 |
-- |
189 |
Kent |