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 1OLDHs-0002Nk-9z for garchives@archives.gentoo.org; Sun, 06 Jun 2010 10:41:04 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B14AEE07D7; Sun, 6 Jun 2010 10:41:00 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 1FD56E0AC6 for ; Sun, 6 Jun 2010 10:40:46 +0000 (UTC) Received: from [192.168.178.22] (p4FDF0F01.dip0.t-ipconnect.de [79.223.15.1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id F189C1B4004 for ; Sun, 6 Jun 2010 10:40:34 +0000 (UTC) Message-ID: <4C0B7B1C.3000009@gentoo.org> Date: Sun, 06 Jun 2010 12:40:28 +0200 From: Thomas Sachau 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3* References: <4BFE82C3.2050400@gentoo.org> <201006051644.20150.Arfrever@gentoo.org> <4C0A720C.20300@gentoo.org> <20100605183154.GA19296@boostbox> <4C0AD7EC.2010700@gentoo.org> <20100605233806.GA17168@boostbox> <4C0B017B.40907@gentoo.org> <87r5kkacr9.fsf@newton.gmurray.org.uk> In-Reply-To: <87r5kkacr9.fsf@newton.gmurray.org.uk> X-Enigmail-Version: 1.0.1 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig0A921A944CADF8F704AA0795" X-Archives-Salt: 258fb2fb-f67d-4502-8631-4d8470964e84 X-Archives-Hash: d49cebcb70340c0703a0582976cc37ea This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A921A944CADF8F704AA0795 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 06.06.2010 08:36, schrieb Graham Murray: > Thomas Sachau writes: >=20 >> Since python-3* is currently useless and not required for any package,= the dependency should by >> default only pull in python-2* like this: >> >> =3Ddev-lang/python-2* >> >> With that, the default way would not pull in a package, which is not n= eeded or used. And if there >> will be any package, which really requires python-3*, it simply reques= ts it in (R)DEPEND of the >> ebuild, which then would overwrite the default value of the eclass and= pull in python-3*. >=20 > That would not work. For example if package 'bar' supports both python-= 2 > and python-3, your mechanism will only build in python-2 support. That > is fine until package 'foo' comes along which uses 'bar' but also > requires python-3 - thus not only must python-3 be pulled in as a resul= t > of foo's (R)DEPEND but also 'bar' must be rebuilt with python-3 support= =2E And that is, how it should be done. Think for example of a package foo, w= hich has a "png" USE flag, which will pull in libpng. By default disabled, it results in disabled pn= g support and libpng not pulled in. Now, when some other package requires foo with png USE flag en= abled, you will have to recompile foo with png USE flag and you will have to install libpng. We h= ave the usedeps of EAPI-2 for it and the package manager does handle it, depending on the user requ= ests. But for optional python-3 support, you cannot control it easily with your= package manager because of the current way, how it is implemented. >=20 > This could be done by adding python2 and python3 USE flags to packages > which support both and only have python2 enabled by default. Then 'foo'= > could have a conditional (R)DEPEMD on 'bar[python3]', but that would > require the user to change the USE flags whereas the current system > handles everything automatically. And automagic behind the scene is exactly, what should not happen. The us= er should be able to control optional dependencies, it should be the same for python like for = any other package. My base proposal for this is something like this: Every package defines the language(s), where it could be installed for mu= ltiple slots, e.g.: MULTI_SLOT=3D"python" or MULTI_SLOT=3D"python ruby" Additionally, it should define the supported slots, something like this: SUPPORTED_RUBY_SLOTS=3D"1.8 1.9" or SUPPORTED_PYTHON_SLOTS=3D"2.5 2.6 3.0 3.1" Now the package manager should take those vars and convert them to some e= xpanded USE vars like: RUBY_SLOTS=3D"1.8 1.9" or PYTHON_SLOTS=3D"2.5 2.6 3.0 3.1" By default, the current active version should be enabled, the others disa= bled. In addition, every dependency, which requires ruby/python should get internal usedeps, so th= at they require the same slots as this package. Every enabled slot should of course pull in that s= lot of the language. With this way, every user can select, which slots he wants to use and whi= ch slots should be installed. And if any package requires an installed version for a specifi= c slot, it can be set in (R)DEPEND (e.g. like DEPEND=3D" python? ( dev-db/foo[pyhon_slot_2.6] )") It would also reduce the amount of code, since we would not have to imple= ment multi-slot support in many different eclasses and it would additionally move the dependency con= trol back to the package manager unlike the current python implementation. I currently have a branch of portage ("multilib-portage"), which can inst= all a package for different platforms, it could be extended to implement the above idea and i plan to= do that. Since i am the only person working on it and me only having limited time and knowledge, = it could still take some time, if noone else wants to step in and help with it. --=20 Thomas Sachau Gentoo Linux Developer --------------enig0A921A944CADF8F704AA0795 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iJwEAQEKAAYFAkwLeyEACgkQG7kqcTWJkGcZfgP/T8U6pZKcPFlq27NIbkI2Cxnt dwyaraqTZYSGeh81xa0YExoTlyieaGKoV+QezJdeZBKrtPuc6+1o9fm5mpTUMoku NxoYyRoUCvQeq0eNaE5sqZhQRpui/j4MYnMvB8BKtM1a9ByylKQc1UDlKPDiMx9A HEdvRuOrmYndoD4HDuU= =FgaN -----END PGP SIGNATURE----- --------------enig0A921A944CADF8F704AA0795--