[gentoo-dev] RFC: PROPERTIES=funky-slots

On Sat, Jun 23, 2012 at 9:21 AM, 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?

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?

On Sat, 23 Jun 2012 10:06:58 -0400
Mike Gilbert wrote:
> > 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?

The 'standard' behaviour (which can be changed by the user) for Paludis
when doing "complete" resolutions is that whenever there's a slot of
something installed, it will try to bring in the newest version of that
package, even if it's in a different slot. This is generally a good
thing, since newer versions are supposed to be better than older
versions. The problem is that now "newer" versions are being used to
mean "with a different Ruby implementation" or "built in a different
way", which screws up the meaning.

On Sat, 23 Jun 2012 10:06:58 -0400
Mike Gilbert wrote:
> > 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?

The 'standard' behaviour (which can be changed by the user) for
Paludis when doing "complete" resolutions is that whenever there's a
slot of something installed, it will try to bring in the newest
version of that package, even if it's in a different slot. This is
generally a good thing, since newer versions are supposed to be
better than older versions. The problem is that now "newer" versions
are being used to mean "with a different Ruby implementation" or
"built in a different way", which screws up the meaning.