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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 985 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mike Gilbert]

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?

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

[Mike Gilbert]

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?

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mart Raudsepp]

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.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alexis Ballier]

On Sat, 23 Jun 2012 17:12:04 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> 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.

When exactly ? You took the gcc example, but it does not have a slot
specified in the 'packages' file so should be upgraded regardless of
slot.

> It's also incorrect behaviour when multiple slots are capable of
> satisfying a dependency.

I suppose that is what Mart meant with 'strictly require'.

I do not know about ruby stuff, but the gtk2/gtk3 case seems a
non-issue to me.

- No slot specified -> best version available, slot independent.
- Slot specified -> best version in said slot.
- Upgrade to new version in a different slot iff something brings in the
  new slot.

If your heuristic brings in gtk3 when everything depends on gtk2, you
should probably rethink your heuristic.

A.

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Marien Zwart]

On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote:
> 
> > 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. 

It surprises me that this behavior is normally desirable for packages
where all dependencies (including any in the world set or the like) are
slotted. The first example that comes to mind here is gtk+: if all
packages a user has installed that depend on gtk+ explicitly depend on
slot 2 (which is probably uncommon now but reasonable back when gtk 3
was introduced), and they do not have gtk+ in their world file (which is
reasonable), do your users really expect the package manager to install
gtk 3? If your package manager has a feature similar to emerge
--depclean, shouldn't this then suggest immediately removing it again,
as nothing depends on it?

I would argue that library versions that can be installed side-by-side,
like gtk+ 2 and 3, "fit the traditional way of how slots worked". But I
think automatically pulling in the latest and greatest version of such a
library only makes sense if code written against the old library stands
a chance of making use of the new library. It might make sense to add a
way to inform your package manager if pulling in new slots by default is
useful, but I would prefer to give this a more obvious name than
"funky-slots", and to come up with a better approach for deciding
whether or not the property should be set than "is SLOTS being used for
something "clever" or not". I would also suggest that the default should
be to *not* pull in new slots by default, but perhaps some review of how
slotting is most commonly used would help decide on that.

-- 
Marien Zwart

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Sat, 23 Jun 2012 22:36:14 +0200
Marien Zwart <marienz@gentoo.org> wrote:
> On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote:
> > > 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. 
> 
> It surprises me that this behavior is normally desirable for packages
> where all dependencies (including any in the world set or the like)
> are slotted.

Think || ( a:3 a:2 ).

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

On Sat, 23 Jun 2012 21:37:11 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 22:36:14 +0200
> Marien Zwart <marienz@gentoo.org> wrote:
> > On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote:
> > > > 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. 
> > 
> > It surprises me that this behavior is normally desirable for
> > packages where all dependencies (including any in the world set or
> > the like) are slotted.
> 
> Think || ( a:3 a:2 ).

So now that you've stated the problem, maybe it's a good time to find
a proper solution for it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Sun, 24 Jun 2012 10:19:19 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > Think || ( a:3 a:2 ).
> 
> So now that you've stated the problem, maybe it's a good time to find
> a proper solution for it.

That isn't the problem. That's an example of an effect of the problem.
The problem is that -r and slots are being used to do something weird.

The proper solution is going to be long term, from the looks of things.
This is a short term damage control operation.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Sun, 24 Jun 2012 11:58:07 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 24 Jun 2012 10:19:19 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > Think || ( a:3 a:2 ).
> > 
> > So now that you've stated the problem, maybe it's a good time to
> > find a proper solution for it.
> 
> That isn't the problem. That's an example of an effect of the problem.
> The problem is that -r and slots are being used to do something weird.

No? What will paludis do in the above case, if the newest version of a
has slot :4?


-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Sun, 24 Jun 2012 13:21:01 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 24 Jun 2012 11:58:07 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sun, 24 Jun 2012 10:19:19 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > > Think || ( a:3 a:2 ).
> > > 
> > > So now that you've stated the problem, maybe it's a good time to
> > > find a proper solution for it.
> > 
> > That isn't the problem. That's an example of an effect of the
> > problem. The problem is that -r and slots are being used to do
> > something weird.
> 
> No? What will paludis do in the above case, if the newest version of a
> has slot :4?

That depends upon other dependencies and what options the user
specifies.

This isn't a Paludis issue, though. It's a "marking where crazy stuff
is being done" issue.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

Le samedi 23 juin 2012 à 21:37 +0100, Ciaran McCreesh a écrit :
> On Sat, 23 Jun 2012 22:36:14 +0200
> Marien Zwart <marienz@gentoo.org> wrote:
> > On za, 2012-06-23 at 17:08 +0100, Ciaran McCreesh wrote:
> > > > 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. 
> > 
> > It surprises me that this behavior is normally desirable for packages
> > where all dependencies (including any in the world set or the like)
> > are slotted.
> 
> Think || ( a:3 a:2 ).
> 
I would say this is not possible with gtk+

To build a gtk+3 app, you need gtk+3 based libs only, same for gtk+2.
Mixing will not work because of symbols conflict iirc.

Anyway, I think that we got off track on the basics of the problem. The
problem is that you cannot have two ebuilds of the same ${CAT}/${PN}
with the same version simply because the files would have the same name.
Adding a new property or whatever does not solve this problem unless we
propose a way of naming such ebuilds to start with, right ?

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

On 23.06.2012 18:17, Ciaran McCreesh wrote:
> 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.
> 

Might be right, but that doesn't allow you to break your own rules.
Plus I still don't get the problem of using SLOTS in the way they are
used now.

And I can't find this out by simply googling. In contrast, an
explanation of multilib in context of linux distribution and more
specific gentoo can be found easily.
But that's nothing I wanted to discuss here.

Stop acting in this arrogant way you are doing right now. This doesn't
make sympathetic in any way and heavily overshadows the technically
skills you will have for sure.

>> 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.

Ever heard about references. They are good, if you don't like to repeat
what is written, but which are necessary context to understand what you
are writing. You should use them for the sake of understanding, if you
are to lazy to write it out again.

> 
>> 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.
> 

My clear vote is No. We shouldn't implement anything which allows bad
coding anywhere, just for the sake of having it "solved" now.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

On Sat, 23 Jun 2012 18:47:26 +0200
Justin <jlec@gentoo.org> wrote:
> On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > 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.
> > 
> 
> Might be right, but that doesn't allow you to break your own rules.
> Plus I still don't get the problem of using SLOTS in the way they are
> used now.

"My own rules" are that enough material is presented that the relevant
people understand it. If you look at simple proposals like usex, silent
rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
very little in the way of text in cases where the change is easily
understood.

> And I can't find this out by simply googling. In contrast, an
> explanation of multilib in context of linux distribution and more
> specific gentoo can be found easily.

Oh really? I was under the impression that there wasn't even general
agreement upon whether or not multilib applied to "C" or to "C, and
Python, and things like it".

> Stop acting in this arrogant way you are doing right now.

Come on. Submitting a simple proposal with at least as much detail as
was provided for other, equally simple proposals is "arrogant" now?

> > That's covered in the devmanual and in the user documentation, so
> > there's no need to repeat it here.
> 
> Ever heard about references. They are good, if you don't like to
> repeat what is written, but which are necessary context to understand
> what you are writing. You should use them for the sake of
> understanding, if you are to lazy to write it out again.

Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
it references what "phase functions" are, or the proposal for usex and
say where it references what "use flags" are, or the proposal for
silent rules where it references what "econf" is.

> >> 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.
> 
> My clear vote is No. We shouldn't implement anything which allows bad
> coding anywhere, just for the sake of having it "solved" now.

The bad coding has already happened. Are you volunteering to revert the
Ruby virtuals?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Justin]

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

On 23.06.2012 18:53, Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 18:47:26 +0200
> Justin <jlec@gentoo.org> wrote:
>> On 23.06.2012 18:17, Ciaran McCreesh wrote:
>>> 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.
>>>
>>
>> Might be right, but that doesn't allow you to break your own rules.
>> Plus I still don't get the problem of using SLOTS in the way they are
>> used now.
> 
> "My own rules" are that enough material is presented that the relevant
> people understand it. If you look at simple proposals like usex, silent
> rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
> very little in the way of text in cases where the change is easily
> understood.
> 
>> And I can't find this out by simply googling. In contrast, an
>> explanation of multilib in context of linux distribution and more
>> specific gentoo can be found easily.
> 
> Oh really? I was under the impression that there wasn't even general
> agreement upon whether or not multilib applied to "C" or to "C, and
> Python, and things like it".
> 
>> Stop acting in this arrogant way you are doing right now.
> 
> Come on. Submitting a simple proposal with at least as much detail as
> was provided for other, equally simple proposals is "arrogant" now?
> 
>>> That's covered in the devmanual and in the user documentation, so
>>> there's no need to repeat it here.
>>
>> Ever heard about references. They are good, if you don't like to
>> repeat what is written, but which are necessary context to understand
>> what you are writing. You should use them for the sake of
>> understanding, if you are to lazy to write it out again.
> 
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
> it references what "phase functions" are, or the proposal for usex and
> say where it references what "use flags" are, or the proposal for
> silent rules where it references what "econf" is.
> 
>>>> 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.
>>
>> My clear vote is No. We shouldn't implement anything which allows bad
>> coding anywhere, just for the sake of having it "solved" now.
> 
> The bad coding has already happened. Are you volunteering to revert the
> Ruby virtuals?
> 


I give up. And actually I don't care anymore.

When I saw the first people leaving this project, because of all this
non social bitching, I thought by myself, this will never happen to me.
But the amount of fruitful discussion here is so less compared to the
shire amount crap coming through, that it is not worth following it.

justin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 302 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

El sáb, 23-06-2012 a las 17:53 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 18:47:26 +0200
> Justin <jlec@gentoo.org> wrote:
> > On 23.06.2012 18:17, Ciaran McCreesh wrote:
> > > 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.
> > > 
> > 
> > Might be right, but that doesn't allow you to break your own rules.
> > Plus I still don't get the problem of using SLOTS in the way they are
> > used now.
> 
> "My own rules" are that enough material is presented that the relevant
> people understand it. If you look at simple proposals like usex, silent
> rules or EBUILD_PHASE_FUNC, you'll see quite clearly that we ask for
> very little in the way of text in cases where the change is easily
> understood.
> 
> > And I can't find this out by simply googling. In contrast, an
> > explanation of multilib in context of linux distribution and more
> > specific gentoo can be found easily.
> 
> Oh really? I was under the impression that there wasn't even general
> agreement upon whether or not multilib applied to "C" or to "C, and
> Python, and things like it".
> 
> > Stop acting in this arrogant way you are doing right now.
> 
> Come on. Submitting a simple proposal with at least as much detail as
> was provided for other, equally simple proposals is "arrogant" now?

Did you send this proposal seriously or only to troll comparing it with
what you think tommy did with multilib thread?

If this is seriously, could you explain more how paludis behave in this
case? Looks like it treats SLOT with major number as latest version,
that is not always true and I don't understand why it should be always
true as there are cases where upstream could release newer 3.0.x
releases that are really newer than 3.1.x versions.

Current -r300/200 stuff shouldn't break as it's only used to slot
libraries and that libs will only be installed when some app RDEPENDs on
them. 

> 
> > > That's covered in the devmanual and in the user documentation, so
> > > there's no need to repeat it here.
> > 
> > Ever heard about references. They are good, if you don't like to
> > repeat what is written, but which are necessary context to understand
> > what you are writing. You should use them for the sake of
> > understanding, if you are to lazy to write it out again.
> 
> Please take a look at the proposal for EBUILD_PHASE_FUNC, and say where
> it references what "phase functions" are, or the proposal for usex and
> say where it references what "use flags" are, or the proposal for
> silent rules where it references what "econf" is.
> 
> > >> 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.
> > 
> > My clear vote is No. We shouldn't implement anything which allows bad
> > coding anywhere, just for the sake of having it "solved" now.
> 
> The bad coding has already happened. Are you volunteering to revert the
> Ruby virtuals?
> 



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Sat, 23 Jun 2012 19:23:57 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> Did you send this proposal seriously or only to troll comparing it
> with what you think tommy did with multilib thread?

Uhm, this proposal is exactly in line with dozens of others that have
been made for EAPI 5. It's simple, low impact and easy to understand.
Please explain for everyone's benefit how you think this proposal is in
any way different to the EBUILD_PHASE_FUNC proposal, or the usex
proposal, or the silent rules proposal.

> If this is seriously, could you explain more how paludis behave in
> this case? Looks like it treats SLOT with major number as latest
> version, that is not always true and I don't understand why it should
> be always true as there are cases where upstream could release newer
> 3.0.x releases that are really newer than 3.1.x versions.

It treats -r300 as being newer than -r200, and so will treat "the gtk3
version" or "the jruby version" as being newer versions of "the gtk2
version" or "the ruby 1.8 version", just as it tries to bring in a
newer GCC and so on.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

El sáb, 23-06-2012 a las 18:30 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 19:23:57 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > Did you send this proposal seriously or only to troll comparing it
> > with what you think tommy did with multilib thread?
> 
> Uhm, this proposal is exactly in line with dozens of others that have
> been made for EAPI 5. It's simple, low impact and easy to understand.
> Please explain for everyone's benefit how you think this proposal is in
> any way different to the EBUILD_PHASE_FUNC proposal, or the usex
> proposal, or the silent rules proposal.
> 
> > If this is seriously, could you explain more how paludis behave in
> > this case? Looks like it treats SLOT with major number as latest
> > version, that is not always true and I don't understand why it should
> > be always true as there are cases where upstream could release newer
> > 3.0.x releases that are really newer than 3.1.x versions.
> 
> It treats -r300 as being newer than -r200, and so will treat "the gtk3
> version" or "the jruby version" as being newer versions of "the gtk2
> version" or "the ruby 1.8 version", just as it tries to bring in a
> newer GCC and so on.
> 

And what problems is that causing for you?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

On Sat, 23 Jun 2012 19:43:10 +0200
Pacho Ramos <pacho@gentoo.org> wrote:
> > It treats -r300 as being newer than -r200, and so will treat "the
> > gtk3 version" or "the jruby version" as being newer versions of
> > "the gtk2 version" or "the ruby 1.8 version", just as it tries to
> > bring in a newer GCC and so on.
> 
> And what problems is that causing for you?

The problem is that there's no way of knowing that -r300 is not "a
newer version" than -r200, and that the jruby implementation is not "a
newer version" than the ruby 1.8 implementation.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

On Sat, 23 Jun 2012 18:45:46 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 19:43:10 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > > It treats -r300 as being newer than -r200, and so will treat "the
> > > gtk3 version" or "the jruby version" as being newer versions of
> > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to
> > > bring in a newer GCC and so on.
> > 
> > And what problems is that causing for you?
> 
> The problem is that there's no way of knowing that -r300 is not "a
> newer version" than -r200

It is a newer version. That's why it has a newer revision.

> and that the jruby implementation is not "a
> newer version" than the ruby 1.8 implementation.

And that's another thing which is ugly and should be replaced by
something sane rather than worked around.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

On Sat, 23 Jun 2012 19:54:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Sat, 23 Jun 2012 18:45:46 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 23 Jun 2012 19:43:10 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> > > > It treats -r300 as being newer than -r200, and so will treat
> > > > "the gtk3 version" or "the jruby version" as being newer
> > > > versions of "the gtk2 version" or "the ruby 1.8 version", just
> > > > as it tries to bring in a newer GCC and so on.
> > > 
> > > And what problems is that causing for you?
> > 
> > The problem is that there's no way of knowing that -r300 is not "a
> > newer version" than -r200
> 
> It is a newer version. That's why it has a newer revision.

That's just it, though -- this no longer holds. -r300 is now being used
for something that is exactly the same version as -r200.

> > and that the jruby implementation is not "a
> > newer version" than the ruby 1.8 implementation.
> 
> And that's another thing which is ugly and should be replaced by
> something sane rather than worked around.

I agree. But until that happens, which probably isn't going to be
anytime soon, we need to know where something weird is happening, and
that's what this proposal provides.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

On Sat, 23 Jun 2012 18:56:42 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 19:54:13 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Sat, 23 Jun 2012 18:45:46 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Sat, 23 Jun 2012 19:43:10 +0200
> > > Pacho Ramos <pacho@gentoo.org> wrote:
> > > > > It treats -r300 as being newer than -r200, and so will treat
> > > > > "the gtk3 version" or "the jruby version" as being newer
> > > > > versions of "the gtk2 version" or "the ruby 1.8 version", just
> > > > > as it tries to bring in a newer GCC and so on.
> > > > 
> > > > And what problems is that causing for you?
> > > 
> > > The problem is that there's no way of knowing that -r300 is not "a
> > > newer version" than -r200
> > 
> > It is a newer version. That's why it has a newer revision.
> 
> That's just it, though -- this no longer holds. -r300 is now being
> used for something that is exactly the same version as -r200.

Did you look at SONAME?

> > > and that the jruby implementation is not "a
> > > newer version" than the ruby 1.8 implementation.
> > 
> > And that's another thing which is ugly and should be replaced by
> > something sane rather than worked around.
> 
> I agree. But until that happens, which probably isn't going to be
> anytime soon, we need to know where something weird is happening, and
> that's what this proposal provides.

Yes, let's introduce some random 'funky' word for a single ebuild. Or..
since it's just a single package, maybe you would just add an ignore
list to paludis.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Sat, 23 Jun 2012 20:09:03 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> > That's just it, though -- this no longer holds. -r300 is now being
> > used for something that is exactly the same version as -r200.
> 
> Did you look at SONAME?

Look at SONAME before deciding what package to install? Kindly explain
how that works.

> > > > and that the jruby implementation is not "a
> > > > newer version" than the ruby 1.8 implementation.
> > > 
> > > And that's another thing which is ugly and should be replaced by
> > > something sane rather than worked around.
> > 
> > I agree. But until that happens, which probably isn't going to be
> > anytime soon, we need to know where something weird is happening,
> > and that's what this proposal provides.
> 
> Yes, let's introduce some random 'funky' word for a single ebuild.
> Or.. since it's just a single package, maybe you would just add an
> ignore list to paludis.

a) it's not a single package, and b) ignore lists in a package manager
is a terrible idea.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

On Sat, 23 Jun 2012 19:06:38 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 20:09:03 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > > That's just it, though -- this no longer holds. -r300 is now being
> > > used for something that is exactly the same version as -r200.
> > 
> > Did you look at SONAME?
> 
> Look at SONAME before deciding what package to install? Kindly explain
> how that works.

I'm just saying that these are two different versions of the package.
If you want GTK+3, you take the newer one. If you want GTK+2 compat,
you take the older slot. What's wrong with that?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Sat, 23 Jun 2012 20:23:13 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Sat, 23 Jun 2012 19:06:38 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 23 Jun 2012 20:09:03 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > > That's just it, though -- this no longer holds. -r300 is now
> > > > being used for something that is exactly the same version as
> > > > -r200.
> > > 
> > > Did you look at SONAME?
> > 
> > Look at SONAME before deciding what package to install? Kindly
> > explain how that works.
> 
> I'm just saying that these are two different versions of the package.
> If you want GTK+3, you take the newer one. If you want GTK+2 compat,
> you take the older slot. What's wrong with that?

The package mangler does not know that 1.1-r300 is not a "better"
version than 1.1-r200, or that 1.2-r200 is not a "better" version than
1.1-r300. Indicating packages where this kind of strangeness happens
allows manglers to know that things that are usually true about the
relationship between slots and versions no longer hold, and that in
these specific cases it should consider slots to be heavily independent.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Alexander]

On Sat, Jun 23, 2012 at 9:22 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 20:23:13 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>> On Sat, 23 Jun 2012 19:06:38 +0100
>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> > On Sat, 23 Jun 2012 20:09:03 +0200
>> > Michał Górny <mgorny@gentoo.org> wrote:
>> > > > That's just it, though -- this no longer holds. -r300 is now
>> > > > being used for something that is exactly the same version as
>> > > > -r200.
>> > >
>> > > Did you look at SONAME?
>> >
>> > Look at SONAME before deciding what package to install? Kindly
>> > explain how that works.
>>
>> I'm just saying that these are two different versions of the package.
>> If you want GTK+3, you take the newer one. If you want GTK+2 compat,
>> you take the older slot. What's wrong with that?
>
> The package mangler does not know that 1.1-r300 is not a "better"
> version than 1.1-r200, or that 1.2-r200 is not a "better" version than
> 1.1-r300. Indicating packages where this kind of strangeness happens
> allows manglers to know that things that are usually true about the
> relationship between slots and versions no longer hold, and that in
> these specific cases it should consider slots to be heavily independent.

You already have this info, it's called a "slot dependency".

-- 
Alex

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Sat, 23 Jun 2012 21:35:47 +0300
Alex Alexander <wired@gentoo.org> wrote:
> > The package mangler does not know that 1.1-r300 is not a "better"
> > version than 1.1-r200, or that 1.2-r200 is not a "better" version
> > than 1.1-r300. Indicating packages where this kind of strangeness
> > happens allows manglers to know that things that are usually true
> > about the relationship between slots and versions no longer hold,
> > and that in these specific cases it should consider slots to be
> > heavily independent.
> 
> You already have this info, it's called a "slot dependency".

It's not a property of individual packages that happen to depend upon
the problematic package. The property holds or not for a package
regardless of whether anything depends upon it.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Alexander]

On Sat, Jun 23, 2012 at 9:37 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 21:35:47 +0300
> Alex Alexander <wired@gentoo.org> wrote:
>> > The package mangler does not know that 1.1-r300 is not a "better"
>> > version than 1.1-r200, or that 1.2-r200 is not a "better" version
>> > than 1.1-r300. Indicating packages where this kind of strangeness
>> > happens allows manglers to know that things that are usually true
>> > about the relationship between slots and versions no longer hold,
>> > and that in these specific cases it should consider slots to be
>> > heavily independent.
>>
>> You already have this info, it's called a "slot dependency".
>
> It's not a property of individual packages that happen to depend upon
> the problematic package. The property holds or not for a package
> regardless of whether anything depends upon it.

They are part of the deal.

If your package has reverse deps, you don't want to update it before
figuring out it's reverse dependencies anyway, you never know what
slot/version restrictions you're going to get.

If it is a package without reverse dependencies, updating to the most
recent slot and/or version should be expected unless the user has the
slot defined in the world file.

-- 
Alex

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Sat, 23 Jun 2012 22:14:32 +0300
Alex Alexander <wired@gentoo.org> wrote:
> If it is a package without reverse dependencies, updating to the most
> recent slot and/or version should be expected unless the user has the
> slot defined in the world file.

That's the part that no longer holds. The package mangler now needs a
way of knowing that for a certain few packages, bringing in new slots
when not explicitly required is undesirable.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Alexander]

On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 22:14:32 +0300
> Alex Alexander <wired@gentoo.org> wrote:
>> If it is a package without reverse dependencies, updating to the most
>> recent slot and/or version should be expected unless the user has the
>> slot defined in the world file.
>
> That's the part that no longer holds. The package mangler now needs a
> way of knowing that for a certain few packages, bringing in new slots
> when not explicitly required is undesirable.

Or the PM can notify the user that a new slot has come up and instruct
them to specify their desired slot in their world file.

-- 
Alex

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Sat, 23 Jun 2012 22:27:03 +0300
Alex Alexander <wired@gentoo.org> wrote:
> On Sat, Jun 23, 2012 at 10:16 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Sat, 23 Jun 2012 22:14:32 +0300
> > Alex Alexander <wired@gentoo.org> wrote:
> >> If it is a package without reverse dependencies, updating to the
> >> most recent slot and/or version should be expected unless the user
> >> has the slot defined in the world file.
> >
> > That's the part that no longer holds. The package mangler now needs
> > a way of knowing that for a certain few packages, bringing in new
> > slots when not explicitly required is undesirable.
> 
> Or the PM can notify the user that a new slot has come up and instruct
> them to specify their desired slot in their world file.

But why? The package mangler could automatically do the right thing,
without requiring help from a user who probably doesn't know about all
of this, if only the small number of packages that did funky things
with revisions and slots said so.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On Sat, 23 Jun 2012 19:22:37 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sat, 23 Jun 2012 20:23:13 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Sat, 23 Jun 2012 19:06:38 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Sat, 23 Jun 2012 20:09:03 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > That's just it, though -- this no longer holds. -r300 is now
> > > > > being used for something that is exactly the same version as
> > > > > -r200.
> > > > 
> > > > Did you look at SONAME?
> > > 
> > > Look at SONAME before deciding what package to install? Kindly
> > > explain how that works.
> > 
> > I'm just saying that these are two different versions of the
> > package. If you want GTK+3, you take the newer one. If you want
> > GTK+2 compat, you take the older slot. What's wrong with that?
> 
> The package mangler does not know that 1.1-r300 is not a "better"
> version than 1.1-r200, or that 1.2-r200 is not a "better" version than
> 1.1-r300. Indicating packages where this kind of strangeness happens
> allows manglers to know that things that are usually true about the
> relationship between slots and versions no longer hold, and that in
> these specific cases it should consider slots to be heavily
> independent.

It *is* a 'better' version, much like gtk+-3.* is 'better' than
gtk+-2.*.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

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

[Matt Turner]

On Sat, Jun 23, 2012 at 1:54 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sat, 23 Jun 2012 18:45:46 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Sat, 23 Jun 2012 19:43:10 +0200
>> Pacho Ramos <pacho@gentoo.org> wrote:
>> > > It treats -r300 as being newer than -r200, and so will treat "the
>> > > gtk3 version" or "the jruby version" as being newer versions of
>> > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to
>> > > bring in a newer GCC and so on.
>> >
>> > And what problems is that causing for you?
>>
>> The problem is that there's no way of knowing that -r300 is not "a
>> newer version" than -r200

It's actually not though, is it? I think -r300 is simply the same
thing as -r200 except that it uses gtk3 instead of gtk2.

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

[Ben de Groot]

On 28 June 2012 13:03, Matt Turner <mattst88@gentoo.org> wrote:
> On Sat, Jun 23, 2012 at 1:54 PM, Michał Górny <mgorny@gentoo.org> wrote:
>> On Sat, 23 Jun 2012 18:45:46 +0100
>> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>>
>>> On Sat, 23 Jun 2012 19:43:10 +0200
>>> Pacho Ramos <pacho@gentoo.org> wrote:
>>> > > It treats -r300 as being newer than -r200, and so will treat "the
>>> > > gtk3 version" or "the jruby version" as being newer versions of
>>> > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to
>>> > > bring in a newer GCC and so on.
>>> >
>>> > And what problems is that causing for you?
>>>
>>> The problem is that there's no way of knowing that -r300 is not "a
>>> newer version" than -r200
>
> It's actually not though, is it? I think -r300 is simply the same
> thing as -r200 except that it uses gtk3 instead of gtk2.

What it means is that it's the same package and version,
but a 100 revisions of the ebuild later. It makes one wonder
what the heck is going on there...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

El sáb, 23-06-2012 a las 18:45 +0100, Ciaran McCreesh escribió:
> On Sat, 23 Jun 2012 19:43:10 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> > > It treats -r300 as being newer than -r200, and so will treat "the
> > > gtk3 version" or "the jruby version" as being newer versions of
> > > "the gtk2 version" or "the ruby 1.8 version", just as it tries to
> > > bring in a newer GCC and so on.
> > 
> > And what problems is that causing for you?
> 
> The problem is that there's no way of knowing that -r300 is not "a
> newer version" than -r200, and that the jruby implementation is not "a
> newer version" than the ruby 1.8 implementation.
> 

Regarding -r300 issue (I don't know much about ruby), I guess paludis
wants to install net-libs/webkit-gtk-1.8.1-r301 for example when nothing
is requiring any specific SLOT? What problems does it cause apart of
what would cause if ebuilds using gtk2 are RDEPENDing on plain
x11-libs/gtk+ without specifying any SLOT? In both cases gtk2 apps
should RDEPEND specifically in SLOTs for gtk2 support and gtk3 apps on
gtk3 slots.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

Le samedi 23 juin 2012 à 18:30 +0100, Ciaran McCreesh a écrit :
> 
> It treats -r300 as being newer than -r200, and so will treat "the gtk3
> version" or "the jruby version" as being newer versions of "the gtk2
> version" or "the ruby 1.8 version", just as it tries to bring in a
> newer GCC and so on. 

I'm stopping my reading of this thread a minute to answer here.

This is actually true when you think of it, gtk3 bindings are newer than
gtk2.
-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ben de Groot]

On 24 June 2012 06:50, Gilles Dartiguelongue <eva@gentoo.org> wrote:
> Le samedi 23 juin 2012 à 18:30 +0100, Ciaran McCreesh a écrit :
>>
>> It treats -r300 as being newer than -r200, and so will treat "the gtk3
>> version" or "the jruby version" as being newer versions of "the gtk2
>> version" or "the ruby 1.8 version", just as it tries to bring in a
>> newer GCC and so on.
>
> I'm stopping my reading of this thread a minute to answer here.
>
> This is actually true when you think of it, gtk3 bindings are newer than
> gtk2.

Now you're playing with semantics. In the case of -r200/-r300 we
are talking about the *exact same* $PV, but for some reason
the revision numbers are confusingly abused for something
that we normally use useflags for (toggling support for specific
toolkits for example).

Please stop abusing revision numbers for something they are
not meant to convey. And please stop pushing developers to
drop perfectly legal usage of the gtk3 useflag.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

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

[Gilles Dartiguelongue]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Le dimanche 24 juin 2012 à 16:48 +0800, Ben de Groot a écrit :
> On 24 June 2012 06:50, Gilles Dartiguelongue <eva@gentoo.org> wrote:
> > Le samedi 23 juin 2012 à 18:30 +0100, Ciaran McCreesh a écrit :
> >>
> >> It treats -r300 as being newer than -r200, and so will treat "the gtk3
> >> version" or "the jruby version" as being newer versions of "the gtk2
> >> version" or "the ruby 1.8 version", just as it tries to bring in a
> >> newer GCC and so on.
> >
> > I'm stopping my reading of this thread a minute to answer here.
> >
> > This is actually true when you think of it, gtk3 bindings are newer than
> > gtk2.
> 
> Now you're playing with semantics. In the case of -r200/-r300 we
> are talking about the *exact same* $PV, but for some reason
> the revision numbers are confusingly abused for something
> that we normally use useflags for (toggling support for specific
> toolkits for example).
> 
> Please stop abusing revision numbers for something they are
> not meant to convey. And please stop pushing developers to
> drop perfectly legal usage of the gtk3 useflag.
> 

This is the same codebase, but they really are slotted libs (that
happens to have the same $PV):
 * different include path
 * different pkgconfig files
 * different sonames
 * ...

If the $PV wasn't the same, there would be no question about have a USE
flag or not, the answer would be obvious to anyone. So please stop
pretending this is a good case for USE flag.

Now if this is the only case (lib with support for two gtk+ versions but
slottable/slotted) that is causing a problem to anyone here, I propose
we go with the simplest fix, have a new package name. That will remember
me of debian packaging :)

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alec Warner]

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

http://devmanual.gentoo.org/general-concepts/slotting/index.html
http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies

I don't think the documentation forbids what these developers are
doing. I think you implemented a nice heuristic for your users in your
resolver that used to work because slots had a typical set of users
cases and the heuristic performed well in those cases.

Now people are occasionally using slots in a different way and your
heuristic penalizes those cases. That sucks, but you might have to
actually change your resolver because I don't think 'funky-slots'
properties is going to garner much adoption. It just appears that the
heuristic you used to use isn't helpful anymore (or has too any false
positives, or whatever.)

-A

>
>> 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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sat, 23 Jun 2012 10:16:42 -0700
Alec Warner <antarus@gentoo.org> wrote:
> I don't think the documentation forbids what these developers are
> doing.

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1

"This means that counting goes as follows: 1.0 (initial version),
1.0-r1, 1.0-r2, etc."

It's not illegal, but it's also not in line with how versions and slots
have interacted up until now.

> I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
> 
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption.

You mean, instead of implementing trivial marking, which takes
developers a few seconds, you want to screw over users? I think that
says a lot about Gentoo's attitude...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alec Warner]

On Sat, Jun 23, 2012 at 10:24 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 23 Jun 2012 10:16:42 -0700
> Alec Warner <antarus@gentoo.org> wrote:
>> I don't think the documentation forbids what these developers are
>> doing.
>
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>
> "This means that counting goes as follows: 1.0 (initial version),
> 1.0-r1, 1.0-r2, etc."
>
> It's not illegal, but it's also not in line with how versions and slots
> have interacted up until now.

I agree and I sympathize with your position.

>
>> I think you implemented a nice heuristic for your users in your
>> resolver that used to work because slots had a typical set of users
>> cases and the heuristic performed well in those cases.
>>
>> Now people are occasionally using slots in a different way and your
>> heuristic penalizes those cases. That sucks, but you might have to
>> actually change your resolver because I don't think 'funky-slots'
>> properties is going to garner much adoption.
>
> You mean, instead of implementing trivial marking, which takes
> developers a few seconds, you want to screw over users? I think that
> says a lot about Gentoo's attitude...

I don't think portage has the behavior that paludis does, so most
users are not likely to experience this particular problem. You know
as well as I that the marking isn't necessarily trivial. Its another
thing we have to document and train people to use. I don't think users
get 'screwed over' either.

It could be that instead of Gentoo tagging a bunch of ebuilds, you
just change your resolver heuristic a bit.

-A

>
> --
> Ciaran McCreesh

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Sat, 23 Jun 2012 10:35:36 -0700
Alec Warner <antarus@gentoo.org> wrote:
> I don't think portage has the behavior that paludis does, so most
> users are not likely to experience this particular problem. You know
> as well as I that the marking isn't necessarily trivial.

But this time it is trivial. That's the point.

> It could be that instead of Gentoo tagging a bunch of ebuilds, you
> just change your resolver heuristic a bit.

The resolver heuristic is correct, except in the cases where people are
doing utterly weird things with revisions and slots.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Kent Fredric]

On 24 June 2012 05:16, Alec Warner <antarus@gentoo.org> wrote:
>>
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies
>
> I don't think the documentation forbids what these developers are
> doing. I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
>
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption. It just appears that the
> heuristic you used to use isn't helpful anymore (or has too any false
> positives, or whatever.)
>


It seems to me that the defacto understanding of slots is that given 2
slots for one package, one slot will be a natural upgrade from another
competing slot, assuming a slot that is a version progression.

This makes sense for most packages.

However, it seems slots are in some cases being used for purposes
other than natural version progressions, and representing siblings
instead of child/parent , and in such case, its not logical to want to
install a different sibling simply for having a different sibling
installed.

So the request is to have some sort of metadata to optionally convey
the intent of what the slot "means", where the defacto method would be
"They're versions,  if X > Y then X is a natural upgrade from Y, and
is slotted for transition and similar reasons" , which would indicate
to UA's that if they have Y, and X becomes available, that they will
want to install X.

And there would be the alternative(s), "Funky slots" , where slots
DONT indicate version progression, and so should *not* be 'upgraded'
to from alternative slots.

Logical place to store such information to me seems <metadata.xml>


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

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

[Patrick Lauer]

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.

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

[Mark Bateman]

Patrick Lauer <patrick <at> gentoo.org> writes:

> 
> 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



So if the packagemanager is struggling to resolve whether a package belongs in a 
slot or not, would this be a case for encoding such metadata in the ebuild 
filename.

foo-slot2-3.2.1.ebuild

This way the PM would be able to determine exactly what it has todo before it 
starts to parse the ebuild 

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

[Brian Harring]

On Mon, Sep 03, 2012 at 02:08:58PM +0000, Mark Bateman wrote:
> Patrick Lauer <patrick <at> gentoo.org> writes:
> 
> > 
> > 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
> 
> 
> 
> So if the packagemanager is struggling to resolve whether a package belongs in a 
> slot or not, would this be a case for encoding such metadata in the ebuild 
> filename.
> 
> foo-slot2-3.2.1.ebuild
> 
> This way the PM would be able to determine exactly what it has todo before it 
> starts to parse the ebuild 

No; the problem isn't getting the slot out of the metadata (moving it 
to the file name doesn't really do anything beyond make it slightly 
faster at the cost of being backwards incompatible for any existent PM 
that sees it); the problem is in the PMs resolver, and how it chooses 
to search the space.

Basically, paludis does x, the rest do y; funky-slots was intended to 
make 'x' behave better at the cost of ebuild devs having to go mark 
shit up (leading to the retort 'do y instead').

~harring