From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SiqZl-0006jI-IO for garchives@archives.gentoo.org; Sun, 24 Jun 2012 17:26:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3E5AE0C72; Sun, 24 Jun 2012 17:26:02 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3121FE0C2D for ; Sun, 24 Jun 2012 17:25:12 +0000 (UTC) Received: from localhost (pc-213-111-101-190.cm.vtr.net [190.101.111.213]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 386F41B42AF for ; Sun, 24 Jun 2012 17:25:11 +0000 (UTC) Date: Sun, 24 Jun 2012 13:25:05 -0400 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: PROPERTIES=funky-slots Message-ID: <20120624132505.1df807b8@gentoo.org> In-Reply-To: <20120623171204.04b3fbec@googlemail.com> References: <20120623142143.631d7ebf@googlemail.com> <20120623151001.705417fb@googlemail.com> <1340461223.21515.39.camel@daedalus.lan> <20120623171204.04b3fbec@googlemail.com> Organization: Gentoo X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 292032e6-548a-462e-999d-528c11557afc X-Archives-Hash: 66c505726457557644d2ebba07c41d92 On Sat, 23 Jun 2012 17:12:04 +0100 Ciaran McCreesh wrote: > On Sat, 23 Jun 2012 17:20:23 +0300 > Mart Raudsepp 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.