Gentoo Archives: gentoo-dev

From: Gilles Dartiguelongue <eva@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
Date: Wed, 27 Jun 2012 07:45:37
Message-Id: 1340783063.16300.4.camel@kanae
In Reply to: Re: [gentoo-dev] RFC: PROPERTIES=funky-slots by Ciaran McCreesh
Le samedi 23 juin 2012 à 21:37 +0100, Ciaran McCreesh a écrit :
> On Sat, 23 Jun 2012 22:36:14 +0200 > Marien Zwart <marienz@g.o> 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@g.o> Gentoo

Attachments

File name MIME type
signature.asc application/pgp-signature