Re: Updated experimental packages
Neil Schemenauer <nas@debian.org> writes:
> I see now that the python2 packages made it into unstable. This is a
> mistake IMHO. The Perl guys tryed this and it didn't work. Also, the
> name should have been python2.1 not python2. What problem does naming
> the packages "python2" solve? It seems like a big pain for everyone
> for no gain.
There have been python2 packages in unstable for months. Just make
one of your packages conflict with python2 and python2-base.
[...]
> Python modules and Python embeding apps should depend on
> "python (>=X.Y), python (<<X.Y+1)". They should install themselves
> into /usr/lib/pythonX.Y/site-packages.
>
> Python programs should depend on "python" or "python (>=X.Y)". They
> should not install any modules in the standard Python path.
My preference would be for virtual packages named "python-x.y" to be
the target of the dependency. This seems to me to allow _more_
flexibility, since _any_ package can then provide the dependency, even
if it can't be named "python" for whatever reason.
> I'm willing to build new version of packages with broken dependencies.
> Can we handle the upgrade from Python by having a long list of conflicts
> in the "python" package?
This shouldn't really be necessary if python-base goes away, should
it?
One "apt-cache showpkg python" later... Except for the packages that
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.
Reply to: