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

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