On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> 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?
