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 <gentoo-dev+bounces-41126-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <tommy@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <tommy@gentoo.org> 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--