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