1 |
On Sat, 23 Jun 2012 15:10:01 +0100 |
2 |
Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
3 |
|
4 |
> On Sat, 23 Jun 2012 10:06:58 -0400 |
5 |
> Mike Gilbert <floppym@g.o> wrote: |
6 |
> > > I don't quite understand why this would be necessary. |
7 |
> > > |
8 |
> > > Would "funky-slots" just be used in situations where ebuilds with |
9 |
> > > the same PV but different PVR have different slots? |
10 |
> > > |
11 |
> > > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is |
12 |
> > > only used in libraries; applications use slot deps to select |
13 |
> > > which one they need. Paludis should not remove the -r200 version |
14 |
> > > if it is still referenced in the depgraph, correct? |
15 |
> > |
16 |
> > Or maybe you are saying that Paludis will not automatically install |
17 |
> > a new slot for a package that is already installed, even when |
18 |
> > referenced by a slot dep? |
19 |
> |
20 |
> The 'standard' behaviour (which can be changed by the user) for |
21 |
> Paludis when doing "complete" resolutions is that whenever there's a |
22 |
> slot of something installed, it will try to bring in the newest |
23 |
> version of that package, even if it's in a different slot. This is |
24 |
> generally a good thing, since newer versions are supposed to be |
25 |
> better than older versions. The problem is that now "newer" versions |
26 |
> are being used to mean "with a different Ruby implementation" or |
27 |
> "built in a different way", which screws up the meaning. |
28 |
|
29 |
I think you should start by describing the problem so we all could |
30 |
understand it, and then we can start thinking about a solution. |
31 |
|
32 |
Is it that Paludis installs a newer SLOT even if a reverse dependency |
33 |
explicitly requests another SLOT? Sounds like a bug to me. |
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |