Re: What should we do now?
On Tue, Oct 23, 2001 at 02:42:42PM +0200, Gregor Hoffleit wrote:
> * Anthony Towns <aj@azure.humbug.org.au> [011023 09:07]:
> > On Tue, Oct 23, 2001 at 01:31:50AM -0400, David M. Cooke wrote:
> > > At some point, Anthony Towns <aj@azure.humbug.org.au> wrote:
[...]
> Just to make the discussion a little bit more focussed: I think several
> issues were mixed up in my original mail:
[...]
Noticed :-)
> As far as I can see, if we hadn't the legacy of the existing packages
> and installations, and if versioned dependencies would work on all
> systems in all situations, we could come up with a quite clean setup:
> python-base et al. could be empty packages (virtual packages wouldn't
> work!), and other packages could depend on them (e.g. "Depends:
> "python-base (>= 2.0), python-gtk" for a package that need at least
> Python 2.0 or better. Still in this case, what could you do if Python
> 2.3 broke that script ?)
This is what we should be (are?) aiming for.
As you point out below, the "safe" way to avoid the "python 2.3 broke that
script" problem is to always use "Depends: pthon-base (>=2.0), python-base
(<<2.3)", and take a punt on it breaking when 2.3 comes out.
> But we haven't an ideal situation, so we have to fight with that kind of
> legacy.
>
> But maybe it brings us to the core of the problem:
>
> As far as I can tell our principal problem is that there's a large set
> of existing packages (from slink, potato) that have wrong dependencies
> (like unversioned "Depends: python-base" for packages that depend on
> Python 1.5.2) that would be (erronously) satisfied if we just continued
> to use python-base and so on.
>
> One way to resolve this is to include a huge list of conflicts in
> python-base et al.
Matthias has done this with his packages. I think this is the way to go.
Sure, we might need to maintain the conflicts for as long as we support back
to potato perhaps... but are we required to support mixed potato/woody
systems anyway? A dist-upgrade will surely upgrade the old stuff away,
provided there are new packages in woody, won't it?
> Another way to resolve this is to drop these package names, perhaps in
> favour of some other package names.
I feel this is ugly... are we going to keep inventing new names every time
we hit this kind of problem?
> IMHO, in the current, messed up situation, scripts and packages that
> play safe in explicitely stating a Python version have the big advantage
> that they will lead to these kinds of problems with underspecified
^
not?
> dependencies.
[...]
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: