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 1NsZQs-0006jn-44 for garchives@archives.gentoo.org; Fri, 19 Mar 2010 10:27:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE6A7E0D4C; Fri, 19 Mar 2010 10:27:55 +0000 (UTC) Received: from mail-pv0-f181.google.com (mail-pv0-f181.google.com [74.125.83.181]) by pigeon.gentoo.org (Postfix) with ESMTP id C126EE0D38 for ; Fri, 19 Mar 2010 10:27:46 +0000 (UTC) Received: by pvg16 with SMTP id 16so1481014pvg.40 for ; Fri, 19 Mar 2010 03:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=KIDQCRbNBKXcclkdql656qF7NngTFNOzjoFJ/MaBDXA=; b=L7pC/phQ2wl4iRhgqRDH18EgYnuw0IPAHtULOg5m56Bq1s4V9pwUjcsig5f6mfS7DW hdm1enEY3+7AUiLby63J1zc5i70uuKd2qW8UcTJdU6hOdWVKgXByue2dNME97xHH1rn0 viLU7b5eoekJbO8b7xDxXObe+hi59IjLgOwEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=iLny3hI9ioE+hO+xBtk1rxmpws1TacaYGpihdhJ555uMDYZ7vOtlZxxDgBw6pG/A1c 07TuuI1b501zOjEapHqOfqOvbeA7yd1HHRAY0rus+3IyrAhdguvTm8wIkh6WqUEh1yqx mEIEx6Nyj7Sfv7OatmyorjRSmT7ihYnbtGEf8= Received: by 10.142.152.17 with SMTP id z17mr533976wfd.45.1268994466320; Fri, 19 Mar 2010 03:27:46 -0700 (PDT) Received: from smtp.gmail.com (c-67-171-128-62.hsd1.wa.comcast.net [67.171.128.62]) by mx.google.com with ESMTPS id 23sm735729pzk.2.2010.03.19.03.27.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Mar 2010 03:27:45 -0700 (PDT) Received: by smtp.gmail.com (sSMTP sendmail emulation); Fri, 19 Mar 2010 03:27:42 -0700 Date: Fri, 19 Mar 2010 03:27:42 -0700 From: Brian Harring To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Packages pulling in python-3*, also they dont require it Message-ID: <20100319102742.GG28451@hrair> References: <4BA27CE2.7080005@gentoo.org> <201003191036.18142.Arfrever@gentoo.org> <4BA3463B.4030204@gentoo.org> <201003191055.04628.Arfrever@gentoo.org> <20100319095608.GE28451@hrair> <20100319100105.2d8fa848@snowcone> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W5WqUoFLvi1M7tJE" Content-Disposition: inline In-Reply-To: <20100319100105.2d8fa848@snowcone> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: 54715f25-612c-4444-b5c1-886e2613d68a X-Archives-Hash: 39235208b1aa2b9de6ebd2d3fa775322 --W5WqUoFLvi1M7tJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 19, 2010 at 10:01:05AM +0000, Ciaran McCreesh wrote: > On Fri, 19 Mar 2010 02:56:08 -0700 > Brian Harring wrote: > > > We are waiting on ABI dependencies (and extended support for > > > multiple ABIs in package manager), which will provide some needed > > > functionality. > >=20 > > You can do it now w/out waiting on ABI dependencies- I'm not saying=20 > > the dependencies would be pretty, but it's doable to get abi level=20 > > depdencies per slotting via expanding out the use combinations. > >=20 > > Note that's a step beyond what's in place now- converting over to the= =20 > > ruby abuse of USE_EXPAND hands over better control to users now w/ > > the same dep gurantees. > >=20 > > So... yeah, it's not reliant on EAPI. An EAPI extension *would* make= =20 > > it easier, but it's not required to do it (especially since the deps=20 > > are already autogenerated to a decent degree). >=20 > How would do it and deal with existing packages not having the required > things in IUSE without (+)/(-) use deps? I don't see a way of doing it > legally without those. Roughly, PYTHON_DEPS=3D"pkg1 pkg2 pkg3" SUPPORTED_PYTHONS=3D"2.6 2.7 3.1" inherit insanely-unfriendly-trickery w/in said eclass, it does a few things 1) IUSE addition of the USE_EXPAND targets for the supported abis 2) take the enabled USE_EXPAND'd flags intersected against=20 SUPPORTED_PYTHON, then set deps/rdeps to=20 """ python_2.6? ( pkg1[python_2.6] pkg2[python_2.6] pkg3[python2.6] ) python_2.7? ( pkg1[python_2.7] pkg2[python_2.7] pkg3[python2.7] ) python_3.1? ( pkg1[python_3.1] pkg2[python_3.1] pkg3[python3.1] ) """ Yes, that is horrible (ciaran you knew it was going to be). Few flaws=20 with it also- 1) edge case when the user turns off all use flags needs addressing-=20 worst case, python eclass forces whatever we consider the 'default'=20 (aka 2.6) 2) python_2.6 isn't actually a valid use flag- it would have to be=20 python_2-6 or python_26 since periods aren't allowed (arfie pointed=20 this out) 3) this can be ugly for users if the PM doesn't treat use flags as=20 tristate- specifically 'explicitly-set', 'explicitly-unset',=20 'indeterminant'. If the ocnfiguration forces an explicit and it=20 conflicts w/ the use dep, ok, configuration needs to be changed. If=20 the use flag is indeterminant, then the PM needs to flip the flag on=20 it's own in that case- I know pkgcore should do this, I don't think=20 portage/paludis do (please correct me if wrong). Thing to note, the deps *would* be accurate- further at the vdb level=20 they'd actually be usable. A dev-lang/python in the vdb is basically=20 unusable since implicitly the pkg that has the dep is built against=20 whatever slottings of python were available at the time- so if you=20 take a pkg from now, a year down the line when py3.2 is stabled as far=20 as the PM can tell that pkg *still* would work if <=3Dpy3.1 were removed=20 (this obviously is not true). Note also that what I laid out above is as far as I know, going a=20 couple of steps beyond what the ruby eclass does (same for what the=20 python eclass does). I'm not necessarily advocating the approach=20 above, but for the raw dev-lang/python dependency we *really* should=20 be using use_expand there- it'll hand folk a fair amount of control as=20 to what abi's get installed into. ~harring --W5WqUoFLvi1M7tJE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEARECAAYFAkujUZ4ACgkQsiLx3HvNzgdNOwCdHIULc2Jgsw6Z0lc65UzABjtz UvsAn0IFj7aiSL01pSFKUzhl1ELuWFyi =YsMl -----END PGP SIGNATURE----- --W5WqUoFLvi1M7tJE--