| 1 |
On Sat, 23 Jun 2012 10:06:58 -0400 |
| 2 |
Mike Gilbert <floppym@g.o> wrote: |
| 3 |
> > I don't quite understand why this would be necessary. |
| 4 |
> > |
| 5 |
> > Would "funky-slots" just be used in situations where ebuilds with |
| 6 |
> > the same PV but different PVR have different slots? |
| 7 |
> > |
| 8 |
> > Taking the gtk2/gtk3 example, I think the -r200/-r300 thing is only |
| 9 |
> > used in libraries; applications use slot deps to select which one |
| 10 |
> > they need. Paludis should not remove the -r200 version if it is |
| 11 |
> > still referenced in the depgraph, correct? |
| 12 |
> |
| 13 |
> Or maybe you are saying that Paludis will not automatically install a |
| 14 |
> new slot for a package that is already installed, even when referenced |
| 15 |
> by a slot dep? |
| 16 |
|
| 17 |
The 'standard' behaviour (which can be changed by the user) for Paludis |
| 18 |
when doing "complete" resolutions is that whenever there's a slot of |
| 19 |
something installed, it will try to bring in the newest version of that |
| 20 |
package, even if it's in a different slot. This is generally a good |
| 21 |
thing, since newer versions are supposed to be better than older |
| 22 |
versions. The problem is that now "newer" versions are being used to |
| 23 |
mean "with a different Ruby implementation" or "built in a different |
| 24 |
way", which screws up the meaning. |
| 25 |
|
| 26 |
-- |
| 27 |
Ciaran McCreesh |
Archives