1 |
On 3 July 2012 20:24, Michał Górny <mgorny@g.o> wrote: |
2 |
> |
3 |
> --depclean? |
4 |
|
5 |
eix Module-Metadata |
6 |
[I] perl-core/Module-Metadata |
7 |
Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9 <--- |
8 |
not unmasked by --autounmask |
9 |
Installed versions: 1.0.6(15:59:00 06/26/12) |
10 |
Homepage: http://search.cpan.org/dist/Module-Metadata/ |
11 |
Description: Gather package and POD information from perl |
12 |
module files |
13 |
|
14 |
[I] virtual/perl-Module-Metadata |
15 |
Available versions: ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1 |
16 |
<----- Unmasked by --autounmask |
17 |
Installed versions: 1.0.9-r1(09:37:51 07/02/12) |
18 |
Description: Virtual for Module-Metadata |
19 |
|
20 |
perl-Module-Metadata-1.0.9.ebuild |
21 |
|
22 |
RDEPEND="|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )" |
23 |
|
24 |
It appears yes, --depclean *will* reap perl-core/* in this scenario ( |
25 |
portage 2.2.0_alpha114 ) |
26 |
|
27 |
Just I don't tend to use --depclean an awful lot. Usually, I don't |
28 |
expect to have to use --depclean to avoid a somewhat "broken" system. |
29 |
|
30 |
> |
31 |
> Doesn't perl-cleaner handle perl upgrades for this? And the tested |
32 |
> ABI_SLOTs should help with that too. |
33 |
|
34 |
ABI_SLOT may be able to help, but the problem is that installing |
35 |
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine. |
36 |
|
37 |
It will just shadow the 2.0 version with the 1.0 version, and assume |
38 |
"that is what you want", while the virtual is trying to convey "That |
39 |
is not what we want". |
40 |
|
41 |
And perl-cleaner doesn't have any code to handle this scenario last I |
42 |
checked. You can't even work out what is the "right" installation |
43 |
scenario without first knowing "what do installed packages want". If |
44 |
"installed packages want version foo to be smaller than 2.0" then |
45 |
perl-core/foo-1.0 being installed on perl-5.10 is "Fine" . For this, |
46 |
they would depend on "<virtual/perl-foo-2" . |
47 |
|
48 |
In essence, you can't tell if the right perl-core/* is installed |
49 |
without first looking that what virtual is installed. |
50 |
|
51 |
|
52 |
> |
53 |
> This is a really fragile approach, and is mostly a workaround |
54 |
> to the real issue. You want to say «I need *only* one of my |
55 |
> dependencies satisfied» while you actually get «if I'm installed, then |
56 |
> let every my dependency in those blocks actually block each other». |
57 |
> |
58 |
> That's just impossible to achieve. Think of ^^ ( foo bar ). When |
59 |
> the package gets installed, foo is installed and bar is not. Then you |
60 |
> want to emerge bar. What should happen? |
61 |
> |
62 |
> a) you want portage to refuse to do that. Why would it? AFAIU this |
63 |
> would no longer be a problem actually. |
64 |
|
65 |
Given |
66 |
|
67 |
C = " ^^( a b )" and you had "A and C" in your world, and you wanted |
68 |
to install B, portage would tell you that to do that, you would have |
69 |
to remove either A or C. ( Yay, the communicative property of XOR :D |
70 |
) |
71 |
|
72 |
> b) you want portage to do that. But you just forced it unmerge it? It |
73 |
> will install the previously made binary package and it's back... |
74 |
|
75 |
I can't parse this statement. Sorry :/ |
76 |
|
77 |
> c) you want portage to unmerge foo because the dep will now be |
78 |
> satisfied by bar. Wait... unmerge perl? |
79 |
|
80 |
No, perl would never be removed, not unless the ^^( ) was simply |
81 |
|
82 |
"^^( perl foo )" |
83 |
|
84 |
In practice, it would be "^^( =dev-lang/perl-5.16* =foo-5.0 )" which |
85 |
would mean |
86 |
|
87 |
a) remove foo |
88 |
b) downgrade/upgrade dev-lang/perl |
89 |
|
90 |
of course, I have noticed a fly in my ointment, in that this logic |
91 |
would mean this blocker could be avoided by down/upgrading foo, which |
92 |
is precisely what we want to avoid. So its back to the drawing board. |
93 |
|
94 |
|
95 |
If we were to discard what we currently know about dependencies for a |
96 |
moment, a dep spec of |
97 |
|
98 |
|
99 |
perl-Foo-5.0: |
100 |
|
101 |
if ( =dev-lang/perl-5.10.0 ) { |
102 |
block versions of perl-core/Foo that are not 5.0 |
103 |
# Because if somebody wants to install perl-core/Foo-5.0 in |
104 |
perl-5.10 , thats fine, its pointless, but its fine |
105 |
# because perl-core/Foo-5.0 'provides' Foo-5.0, as does |
106 |
perl-5.10, so this is satisfactory behaviour |
107 |
} else { |
108 |
install perl-core/Foo-5.0 and only perl-core/Foo-5.0 |
109 |
# Because something has stated that it "wants" Foo-5.0 for some reason, |
110 |
# So we must deliver it at all costs. If its not shipped in |
111 |
perl, then we provide it. |
112 |
} |
113 |
|
114 |
It would be nice to be able to just say "Fine, how about we just |
115 |
always install from perl-core/". |
116 |
|
117 |
Which hits the road block as soon as upstream release dev-lang/perl |
118 |
with Foo-5.01 , and Foo-5.01 is not available on CPAN. ( Sometimes its |
119 |
a 'dev' release, other times its not ) . |
120 |
|
121 |
Better approaches welcome. |
122 |
|
123 |
I have thought of scrapping the virtuals entirely and handling it so |
124 |
that things depend on perl-core/* instead, and perl-core can just |
125 |
dynamically decide at install time whether or not it needs to no-op ( |
126 |
and sometimes perl-core/* will need to hard depend on perl and just |
127 |
install nothing ). |
128 |
|
129 |
This seems a simpler approach until you consider the problem of "How |
130 |
do we determine dependencies for this ebuild". |
131 |
|
132 |
Messy. :/ |
133 |
|
134 |
With API_SLOTS I guess we can (maybe) have api-slot conditional |
135 |
SRC_URI and DEPEND values, |
136 |
|
137 |
# Not real code, just pesudocode |
138 |
SRC_URI=" ! API-Perl-5.10 ? ( ..... ) " |
139 |
|
140 |
DEPEND=" ! API-Perl-5.10 ? ( ..... ) " |
141 |
|
142 |
Or some shit like that. |
143 |
|
144 |
If we're really really keen, we might be able to throw it together |
145 |
with some USE_EXPAND , it might be tidier, it might not be. |
146 |
|
147 |
|
148 |
-- |
149 |
Kent |
150 |
|
151 |
perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, |
152 |
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" |
153 |
|
154 |
http://kent-fredric.fox.geek.nz |