On Mon, Jun 16, 2008 at 12:09:54PM -0700, Jordan Brown wrote:
> 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.
Ah, good. I don't think I've encountered this ever, but it is good
to know this is supported. Reinforces my suspicion that SVR4
packaging is not as outdated as people make it out to be.
>>> 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?
All Linux package dependency mechanisms? RPM, Slack, Deb, Portage,
Conary? Is it because these package managers are broken or is it
because of the sheer variety of applications and their combinations
they need to support? If it is the latter, will we be immune to
those problems because we eventually want to support most of those
applications?
> 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?
In case of Python, you would normally install version 2.1. Not
a general rule for all packages though. More below.
> 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.
If this is a choice you (as the user) or the package manager has to
make, then the package or the package manager is broken. The
decision on whether a new release of a package is compatible with
the previous release is up to the package maintainers to make. In
this case, the distributors of Python and the application that uses
Python need to make this decision. Python certifies if the new
release is completely compatible with the old one (in this case, no)
and the application maintainer decides if it can work with newer
releases of Python.
All that the package manager has to do here is to be able
accommodate those choices -- and one of these requires that it is
possible to mark a new release as incompatible with the old one.
Once that is supported, the packaging system has a choice of
supporting multiple incompatible independent versions or shutting
out some applications from the system completely until they are made
compatible.
A real world example -- Getmail versions upto 3 were compatible.
Getmail 4 is not. Without support from the package maintainer, how
is the package manager supposed to figure this out?
> 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.
And yet, Debian and Gentoo which support these kinds of dependencies
continue to thrive.
>>> 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.)
Without even contesting this point (though quite a few exceptions
come to mind), may I remind you that was your example? :) I must
admit I have never encountered a machine running more than one mail
server but I have encountered tons running more than one HTTP
server, which has the same issues. I have personally installed
machines which needed both Apache 1.x and Apache 2.x because
different web applications needed different Apache modules.
>>> 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?
Laca addressed this point already. All non-trivial python scripts
use the #!/usr/bin/pythonX.Y form. The /usr/bin/python link is just
a convenience for simple scripting and command-line use.
> 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.
I'm not entirely sure what you are getting at here, but in general
this is up to the user. If that is what you mean by policy,
I totally agree with you. And mechanisms like update-alternatives
and eselect allow a user to set and change this policy.
> 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?
Yes, except that it'd be the package manager's responsibility to
find a copy of Python 2.3.
> Do you assume that 2.4 is compatible?
Not unless Python's maintainer (which could be Sun or the
OpenSolaris community) certifies 2.4 as compatible with 2.3. This
is not a decision for the package manager to make independently, and
it is definitely not a decision the user should be forced to make.
> Do you throw away this lousy
> incompatible infrastructure and buy one that promises compatibility?
How? You mean fix Python 2.4 so that it is completely compatible
with 2.3 and all previous releases? Or fix every application which
depends on older versions of Python? Or just disallow packages
which cannot work with newer releases of Python? And just how does
an infrastructure, however good it might be, promise or even attempt
to provide compatibility between releases of the packages it deals
with?
No packaging system, however good, is going to change the world.
There are applications which do not maintain compatibility between
releases and there are applications which depend on different
incompatible versions. A packaging system has to either deal with
it or be content to settle for a niche market.
Venky.
--
One hundred thousand lemmings can't be wrong.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
