1 |
On Sat, Jun 23, 2012 at 10:02 AM, Mike Gilbert <floppym@g.o> wrote: |
2 |
> On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh |
3 |
> <ciaran.mccreesh@××××××××××.com> wrote: |
4 |
>> There's been a move towards using slots for "clever" things that don't |
5 |
>> fit the traditional way of how slots worked. Examples include the new |
6 |
>> gtk2 / gtk3 handling and Ruby gems virtuals. |
7 |
>> |
8 |
>> Aside from being abusive, this screws things up for Paludis users. |
9 |
>> Paludis tends to bring in newer versions when possible (so that users |
10 |
>> aren't stuck with an old GCC forever), and allows the user to select |
11 |
>> when new slots are brought in. When suddenly a few packages are using |
12 |
>> slots and versions to "mean" something other than what they used to, |
13 |
>> this makes the feature unusable. |
14 |
>> |
15 |
>> Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES |
16 |
>> value called "funky-slots", which should be set on every version of any |
17 |
>> package that uses slots in an unconventional manner. This probably |
18 |
>> doesn't need EAPI control, since package manglers are free to ignore |
19 |
>> PROPERTIES tokens. It won't solve the abuse, but it will allow the |
20 |
>> impact upon users to be lessened. |
21 |
>> |
22 |
>> -- |
23 |
>> Ciaran McCreesh |
24 |
> |
25 |
> I don't quite understand why this would be necessary. |
26 |
> |
27 |
> Would "funky-slots" just be used in situations where ebuilds with the |
28 |
> same PV but different PVR have different slots? |
29 |
> |
30 |
> Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only |
31 |
> used in libraries; applications use slot deps to select which one they |
32 |
> need. Paludis should not remove the -r200 version if it is still |
33 |
> referenced in the depgraph, correct? |
34 |
|
35 |
Or maybe you are saying that Paludis will not automatically install a |
36 |
new slot for a package that is already installed, even when referenced |
37 |
by a slot dep? |