RFC: PROPERTIES=funky-slots
 

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

RFC: PROPERTIES=funky-slots
 

On Sat, Jun 23, 2012 at 10:02 AM, Mike Gilbert <floppym@gentoo.org> wrote:
> On Sat, Jun 23, 2012 at 9:21 AM, Ciaran McCreesh
> <ciaran.mccreesh@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?

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?

RFC: PROPERTIES=funky-slots
 

On Sat, 23 Jun 2012 10:06:58 -0400
Mike Gilbert <floppym@gentoo.org> 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.

--
Ciaran McCreesh

RFC: PROPERTIES=funky-slots
 

On L, 2012-06-23 at 15:10 +0100, Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 10:06:58 -0400
> Mike Gilbert <floppym@gentoo.org> 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.

Don't do that if the slotted package in question is not in the @world,
and all packages depending on it strictly require the older SLOT.

RFC: PROPERTIES=funky-slots
 

On Sat, 23 Jun 2012 15:10:01 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 10:06:58 -0400
> Mike Gilbert <floppym@gentoo.org> 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.

I think you should start by describing the problem so we all could
understand it, and then we can start thinking about a solution.

Is it that Paludis installs a newer SLOT even if a reverse dependency
explicitly requests another SLOT? Sounds like a bug to me.

--
Best regards,
Michał Górny

RFC: PROPERTIES=funky-slots
 

On Sat, 23 Jun 2012 17:51:01 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> I think you should start by describing the problem so we all could
> understand it, and then we can start thinking about a solution.

It's simple: abusing versions and slots invalidates what is otherwise
sensible logic. Thus in the long term we need to stop abusing versions
and slots, and in the short term a mechanism is needed to indicate
where this abuse happens. This is the short term fix.

> Is it that Paludis installs a newer SLOT even if a reverse dependency
> explicitly requests another SLOT? Sounds like a bug to me.

No, it's that if a user requests a "complete" resolution, Paludis
installs the newest version of things that it can. Extensive
consultation with users has shown that this is a good behaviour, except
in the small number of situations that have recently arisen where
people are doing weird things with versions and slots.

--
Ciaran McCreesh

RFC: PROPERTIES=funky-slots
 

On Sat, 23 Jun 2012 17:20:23 +0300
Mart Raudsepp <leio@gentoo.org> wrote:
> > 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.
>
> Don't do that if the slotted package in question is not in the @world,
> and all packages depending on it strictly require the older SLOT.

That is an option Paludis provides for users, but doing so leads to old
versions of things lying around when an upgrade is preferred. It's also
incorrect behaviour when multiple slots are capable of satisfying a
dependency.

--
Ciaran McCreesh

RFC: PROPERTIES=funky-slots
 

On 23.06.2012 15:21, 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.
>

Did you read what you wrote and thought about what you request from
others? Probably you better should.

I can't see any good and more importantly, sufficient description of the
problem. There is some vague hint, that paludis is not able to solve
dependency chains correctly, but this is something I might got wrong
from your mail.

An example:

"...slots and versions to "mean" something other than what they used to,..."

is completely useless without a description of what SLOTS are about and
how the should be used. And what is the wrong usage you can find;
examples are necessary here for understanding.


And your approach (a workaround called "funky-slots") to tackle this
what-ever-the-problem-really is, doesn't fit to anything you want from
others.
To me, it doesn't solve the root cause, but actually I can't judge this,
because I am missing a description of what is really going wrong.


Don't behave in a way, which you disallow for others.

justin

RFC: PROPERTIES=funky-slots
 

On Sat, 23 Jun 2012 18:13:23 +0200
Justin <jlec@gentoo.org> wrote:
> Did you read what you wrote and thought about what you request from
> others? Probably you better should.

Uh huh, and I think we all know there's a huge difference between
knowing what versions and slots are and knowing what "a multilib" is.

> An example:
>
> "...slots and versions to "mean" something other than what they used
> to,..."
>
> is completely useless without a description of what SLOTS are about
> and how the should be used. And what is the wrong usage you can find;
> examples are necessary here for understanding.

That's covered in the devmanual and in the user documentation, so
there's no need to repeat it here.

> To me, it doesn't solve the root cause, but actually I can't judge
> this, because I am missing a description of what is really going
> wrong.

As I've already said, this isn't about solving the root cause. It's
about reducing the impact of damage that's already been done until the
root cause is solved properly.

--
Ciaran McCreesh

RFC: PROPERTIES=funky-slots
 

On 06/23/12 21:21, 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,
No, it solves a real problem.
> this screws things up for Paludis users.
-EDONTCARE, use a supported package manager
> 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.
>
Hackfix. Hardcode those packages in paludis if you need to. Cleaner and
faster quick workaround until you can figure out a clean solution.

No reason to hack a working solution to bits, especially as it is rather
easy to mask specific versions if they annoy you (as I do to keep my
systems gtk3-free). The current solution is a side-effect of some
upstreams being very confused, but I like the -r200/-r300 versioning fix
for gtk apps.