Venky wrote:
> On Fri, Jun 13, 2008 at 08:52:24PM -0700, Jordan Brown wrote:
>> Installing multiple versions of a package is a solved problem. SVR4 has
>> done it forever.
>
> If I remember right, this is done by adding version metadata in
> the package name (SUNWapache2, etc.). This would be possible
> with IPS too, but is not a solution.
You remember wrong. SVR4 packaging requires that the combination of
{PKG, VERSION, ARCH} is unique. You can have as many instances of
SUNWfoo installed as you like, as long as they differ in either VERSION
or ARCH.
Because of upgrade issues and the difficulties of working with multiple
instances with the same package names (including dealing with software
that does not understand the possibility), we do tend not to use this
capability.
>> Actually *using* multiple versions of packages with non-trivial
>> dependencies is quite another matter. I suspect it's solvable only in the
>> extreme cases where either (a) you can assume that newer versions are
>> completely compatible, or (b) you assume that newer versions are *never*
>> compatible.
>
> Don't see any reason why these are the only ways to solve it. I
> am not that familiar with Debian alternatives, but portage
> handles this quite well without having to assume either (a) or
> (b). Gentoo lists over 700 packages in its repository which use
> slots right now.
Do I need to point out that Linux package dependency management is
widely considered an almost impenetrable morass?
However, I think you miss my point. It matters little how the files get
onto the system. What is difficult is choosing which files need to get
onto the system, and using them once they get there.
Making up version numbers, if you have an application from 2003 that
calls out a dependency on Python 2.1, what do you do?
Your basic choices are to assume that Python 2.4 is compatible with 2.1,
and arrange (somehow) to use a Python 2.4 to run it, or to assume that
2.4 is *not* compatible with 2.1 and somehow acquire a 2.1 to run it.
You could, I suppose, fully retest the application with 2.4...
expensive, and very difficult if it's not your application.
That's a simple case. When you start to factor in applications and
libraries that must interface with one another, you can easily end up in
a gridlock situation where you cannot upgrade any component because
doing so would require updating another component, and another, and
another, until you must upgrade the entire system. Better hope that
nobody finds a killer security bug in any of the components.
>> The situation gets worse when you consider components that require
>> exclusive use of some resource. In general, you can't have two mail
>> servers, because only one can listen on port 25.
>
> This is more of a configuration problem than a packaging one.
Exactly. Packaging is the easy part of the picture.
> In this case, they would just need to listen on different ports.
A mail server listening on any port other than 25 is, in general, a very
boring and lonely mail server, because just about exactly zero mail
transfer agents are willing to send mail on any other ports. One of the
reasons that mail flows so relatively well between independently
administered systems is that it all flows on port 25. (There are a few
exceptions, but they are all quite localized and under centralized
administration.)
>> The "what does /usr/bin/python get you" question is not a packaging
>> question. It's a "how do you *use* multiple versions" question.
>
> Not sure I get the distinction, but this again has been solved by
> Debian (update-alternatives) and portage (eselect). Not every
> package needs this, by the way. A lot of them (like BerkeleyDB)
> provide independent libraries or utilities which coexist quite
> peacefully.
Say that you have every version of Python ever created installed.
What version does /usr/bin/python get you?
The actual implementation of setting up /usr/bin/python is indeed a
packaging question, but the _policy_ is not; the policy is independent
of the packaging system.
Alternatively, suppose that you have Python 2.1 and Python 2.4
installed, and you have an application that wants /usr/bin/python2.3.
What do you do? Do you just fail, and insist that the administrator
find a copy of Python 2.3? Do you assume that 2.4 is compatible? Do
you throw away this lousy incompatible infrastructure and buy one that
promises compatibility?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
