Re: coming back to packaging multiple versions of libraries
On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski <piotr@debian.org> wrote:
> what's the point of installing two different versions of the same module
> if only one will be used anyway? If the answer to that question is:
> "in the application where I need different version, I will adjust
> sys.path" - why not simply provide different version of the library as
> private module? Security team will hate you anyway.
For the same reason we support libreadline5 and 6 : to transition
higher level code without a flag day across the entire machine.
Security team should not hate this any more or less than they do for C
libraries, its for precisely the same reasons.
>> I'm very interested in other approaches to make this work;
>
> teach upstream about the importance of stable API (yeah, I know Python
> programmers do not care about it much, it could be worse¹, though)
The best of intentions still sometimes leads to incompatible changes,
but yeah, preach it :).
> You could also provide wadllib/__init__.py file which will modify
> __path__ to point to the newest installed versions (and f.e. check for
> WADLIBVERSION env. variable if someone doesn't want the newest version)
> but it's an ugly hack and could cause more harm than good, IMHO.
I can see that breaking overly-clever packages, or things like the
twisted splitup, bzrlib.plugins etc. I'd like to be minimally
invasive.
@Barry: yes, the C/C++/CLR/ library handling is precisely equivalent.
I would expect only as many concurrent versions in the archive as we
need to support. There are two use cases:
- in sid, while transitioning an incompatible change
- users using private packages with their own archive
In the former case, we'd generally(1) drop an old version as soon as
its rdepends(2) is empty. In the latter case, its up to the user to
decide when they don't need a particular version.
(1) Exceptions might occur if a maintainer feels that the package is
extremely widely used outside of the packaging universe and wants to
keep it available.
(2) Figuring out rdepends sanely is another step to be taken, but I'm
hoping to break this down far enough to get consensus on individual
bits.
It really does look like having better upstream facilities would make
this a no-brainer for us; what I'd like to achieve though is something
that /works/ for the existing python platform - for 2.7 which will be
around a good long time, and then we'll have plenty of data to discuss
with upstream.
-Rob
Reply to: