1 |
On 06/23/12 21:21, Ciaran McCreesh wrote: |
2 |
> There's been a move towards using slots for "clever" things that don't |
3 |
> fit the traditional way of how slots worked. Examples include the new |
4 |
> gtk2 / gtk3 handling and Ruby gems virtuals. |
5 |
> |
6 |
> Aside from being abusive, |
7 |
No, it solves a real problem. |
8 |
> this screws things up for Paludis users. |
9 |
-EDONTCARE, use a supported package manager |
10 |
> Paludis tends to bring in newer versions when possible (so that users |
11 |
> aren't stuck with an old GCC forever), and allows the user to select |
12 |
> when new slots are brought in. When suddenly a few packages are using |
13 |
> slots and versions to "mean" something other than what they used to, |
14 |
> this makes the feature unusable. |
15 |
> |
16 |
> Thus, as a quick workaround, I'd like to suggest adding a PROPERTIES |
17 |
> value called "funky-slots", which should be set on every version of any |
18 |
> package that uses slots in an unconventional manner. This probably |
19 |
> doesn't need EAPI control, since package manglers are free to ignore |
20 |
> PROPERTIES tokens. It won't solve the abuse, but it will allow the |
21 |
> impact upon users to be lessened. |
22 |
> |
23 |
Hackfix. Hardcode those packages in paludis if you need to. Cleaner and |
24 |
faster quick workaround until you can figure out a clean solution. |
25 |
|
26 |
No reason to hack a working solution to bits, especially as it is rather |
27 |
easy to mask specific versions if they annoy you (as I do to keep my |
28 |
systems gtk3-free). The current solution is a side-effect of some |
29 |
upstreams being very confused, but I like the -r200/-r300 versioning fix |
30 |
for gtk apps. |