Il mar, 2004-06-15 alle 17:13, Cory Dodt ha scritto:
> There is an implicit assumption here that python modules will actually work
> for all versions of Python. This is clearly not the case; some will use
> features only available in (some newer version X.y). Furthermore, at least a
> few (distutils and difflib are notable) are available only for the versions in
> which they would not normally be available anyway. (They were added to the
> stdlib later, iirc.) It would be undesirable to package them for later
> versions and do extra work pulling those parts out of the stdlib, and probably
> impossible to package them for earlier versions since they would not work.
Yes, I know there are some packages which can't compile with older
version, but there are some which can but Debian doesn't do.
Cory: it is not an implicit assumption, distutils and difflib are not
good example :) Here there is my example: python-slang (I haven't
nothing against the mantainer of this package, this is not a flame!).
delisark:~> apt-cache show python-slang
Package: python-slang
Version: 0.2.0-7.1
Depends: libc6 (>= 2.3.2-1), slang1 (>> 1.4.4-7.1), python (>= 2.3),
python (<< 2.4)
Package: python-slang
Version: 0.2.0-6
Depends: libc6 (>= 2.2.4-4), slang1 (>> 1.3.0-0), python (>= 2.1),
python (<< 2.2)
In stable there is a python-slang compiled for python2.1, in testing and
unstable there is a python-slang compiled for python2.3... What about
python2.2? If I apt-get python2.2, why I can't use slang?
I know the number of packages in Debian is becoming a problem, simply I
don't uderstand why python2.1 (and a lot of modules for python2.1) are
available in testing (which will be stable soon) if it is an old version
and two major versions have been released after it. My opinion is that
if there are too packages, lets drop old versions of python from sarge
(like python2.1 and python2.1-*).
> Josselin Mouette wrote:
> I think this would be wrong. This would clutter the archive with loads
> of cruft. For modules that are not widely used, almost no one will want
> a package for an older python version, thus only the default current
> version should be supported. This makes the python transitions easier,
> too.
Josselin: I don't agree, but I understand what you said... But IMHO
the python transitions are made easier also with a dummy package which
depends on the default current versions of python packages. This is
my personal opinion: I think if Debian supports python2.x, should
supports every python2.x module without differences between widely
and not widely used modules... I love Debian because I can choose
what I can install. As you explained, the mantainer have to choose if a
module is widely used or not, and if it's a good idea to package it
for older versions. But this is only my opinion, so don't answer me
for this point, as I said this is not a flame :)
> Seo Sanghyeon wrote:
> | I agree, so I am against Fabio's suggestion to make all Python module
> | packages to support all Python versions. But the fact python-gd have a
> | wishlist bug filed specifically asking for other versions of Python
> | means that it is widely used enough...?
This is a good question... I'd like to adopt python-gd, I found a bug
which require the module compiled for old versions of python... What I
have to do? How can I choose to consider it enough diffuse and widely
used to package it also for old versions of python? And which versions?
Only python2.2 or also python2.1?
I'm new in Debian so I don't know every procedure in it... I'm sorry
if I do some mistakes or some stupid questions, but I'm very curious
about the right policy packaging debian modules.
Thanks for the discussion,
Fabio.
--
Fabio Tranchitella
<!> kobold.it, Turin, Italy - Free is better!
-----------------------------------------------------------------------
<http://www.kobold.it>, <kobold@kobold.it>, <kobold@jabber.linux.it>
-----------------------------------------------------------------------
GPG Key fingerprint: 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
Attachment:
signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata