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