Martin Schulze wrote:
I'd rather know about the vulnerability (and maybe doko is able to
implement a fix) than to blindly castrate software. Theo d.R. already
taught us that blindly releasing updates are not good.
Here's some relevant links for the bugs:
Deleting __builtins__:
http://python.org/
Donovan Baarda wrote:
But this is redundant... if the package is installed, the corresponding *.py
files _should_ be unpacked. How is testing for the existance of a file any
better indication than testing for installation of the package?
True... I think I'll try to blame my flawed argument on lack
Donovan Baarda wrote:
finding all packages that depend on "python" is non-trivial using only dpkg.
Something like dpkg-awk, grep-dctrl, or python-apt make it much easier, but
do we want to depend on them? The old "registry" idea would have made this a
little easier, but I still prefer using the dpk
conflict with python-base itself, they don't
need to conflict with packages that depend on python-base. I think
the first `python-base' needs to be removed.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"
testing and unstable,
then it looks like only bg5ps, grmonitor, pythondoc and sketch would
need to be included in this list, making it even simpler. It's even
possible some of them still work with Python 2.1.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"
Matthias Klose <[EMAIL PROTECTED]> writes:
> Carey Evans writes:
>
> > Another possibility is for python-base to go away, and for a new
> > package that conflicts with it, and has a different name, to take its
> > place.
>
> basically that is Neil's pro
quot;python", and around 101 that depend on python-base
only once.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"
combinations of packages can be installed.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"
I notice that python2.1-base depends on libssl0.9.6. I haven't been
following the developments in Debian's crypto policy, but doesn't this
mean that python2.1-base should have been uploaded to non-US?
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
ume it's actually
., i.e. >=1.5 and <<1.6, >=2.1 and <<2.2, >=2.9 and <<2.10, etc.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Ha ha! Puny receptacle!"
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> spam should depend on python not python-2.1.
In my original example, spam embeds libpython2.1.so. It would make
sense for this to mean it depends on python-api-2.1, though this isn't
what the current shlibs file says.
--
e to upgrade it because spam's
dependencies would be broken.
I guess it might be worth having python-api-2.x anyway, to make sure
nothing gets upgraded until all packages are at the new version.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
.
The best solution I can see at the moment is for eggs to provide
something like "python-2.1-eggs", and for spam to depend on that.
Then when eggs is recompiled for Python 2.2, it provides
"python-2.2-eggs", and apt doesn't upgrade anything until spam is
recompiled for P
depend on "python". Another advantage of the package being
"python2.1" is that these packages don't need to be conflicted with,
if they really mean Python 1.5.2.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
parts of
the packaging system, include update-alternatives itself, are written
in Perl.
I think the latter point is also a contributor to Perl not using
alternatives for /usr/bin/perl.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
there'll be one package per Python version?
- What should packages that use Python depend on? Presumably
"python" if the maintainer feels optimistic, otherwise
python2.1-base.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
n "python", which is a
virtual package, and it looks like it used to be a real package. Try
"apt-cache showpkg python".
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
oken dependencies either, so this doesn't really cause
much hardship.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
all python2.1-base, or whatever.
(However, it's quite possible I don't understand how apt makes its
decisions.)
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
You think you know... what's to come... what you are.
2.1.1 anyway.
[...]
> Do we need python2.0-* as well ?
I don't think so. Realistically, will we ever need more than one
Python 2.x version in stable at any time? Perl seems to cope with
just one version, even though Perl 5.005 and 5.6 have enough changes
to break code for 5.004.
--
to date
unstable, so maybe I don't have the same perspective as many users. ;)
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
s from argv[0] in Py_Main(), looking in
$PATH if necessary.
os.system isn't the best in terms of signal handling and return
values; you'd probably want os.execv.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
an do what you
> like with the idea.
I probably shouldn't be using my @debian.org address for this
discussion anyway; I've done one package upload in the last six
months, which hardly makes me an active Debian maintainer or any kind
of authority.
I'm not really talking just to
Can I suggest that with only a few weeks until Python freezes,
anything like this is left until the following Debian release? That
will give us several months to iron out any bugs in the script, and in
the packages using it, before time runs out.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
e you
to do a new upload between releases anyway.
IMO, the minimal effort required here isn't worth the black magic.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
to only expect them to work with
the current version, in any stable release of Debian. As the language
changes, adding keywords like "yield" and "div", etc., expecting full
forwards compatibility might be a little unreasonable.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
ad for a Debian package is another question.
...
Wow. That got a bit longer than I anticipated. If anyone got down to
here, do you have any comments? I can expand on my reasoning if it
would help.
Thanks.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
anyway, for maintainers and
for the packaging system, so that modules can have a simple depends
on a (maybe virtual) package, instead of a versioned depends.
(Does dpkg support versioned virtual packages yet?)
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
tly
even when the source isn't in sys.path.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
nt
of view, and something to make sure the latest version is available
after a dist-upgrade. Though that leaves the problem of the packages
currently depending on "python"...
If it's any consolation while you're trying to work out a plan, just
be glad Python isn't "Essential: yes" like parts of Perl.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
"Quiet, you'll miss the humorous conclusion."
;d be nice just to have Python 2.1 in woody before the
freeze, whether or not it's GPL compatible. Or even get more Python
1.5 packages built for Python 2.0 as well.
Is there anything I can do myself to help with the Debian Python
packages?
--
Carey Evans http://hom
"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
> last I checked it only helped derivatives of python, not python itself.
AIUI, the point is that Python 2.1 is a derivative of CNRI Python 1.6.1.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
uot; or "license" for more information.
>>> import zlib
WARNING: Python C API version mismatch for module zlib:
This Python has API version 1009, module zlib has version 1007.
Here zlibmodule.so from 1.5.2 is in my $PYTHONPATH.
It didn't actually crash, though.
--
Carey Evans http://home.clear.net.nz/pages/c.evans/
33 matches
Mail list logo
