Venky wrote: >> 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?
Because of the variety of applications and their combinations. > If it is the latter, will we be immune to > those problems because we eventually want to support most of those > applications? Nope. The problems are independent of the package subsystem. The best that the package subsystem can do is not make them worse. > 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. Right. Packaging is the easy part of the picture. >> 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. Do they? What fraction of the marketplace do they have? Sure, they're popular with people who like to play around with their computers. Are they popular with people for whom the computer is a tool for accomplishing their real goal, and for whom every minute spent dealing with some computer-management issue is a minute wasted? >>> 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? :) Yes, of course it was. My point is that you can't have two mail servers, because only one of them can have port 25. > 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. No, it doesn't. HTTP provides for mechanisms for specifying an alternative port as part of a URL. SMTP doesn't. (I did pick my example carefully :-) >> 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. Right. And I am contending that it is this policy issue - how do you *use* multiple versions - that is the difficult part of the picture. If infrastructure components (like Python) do not guarantee compatibility, then the only alternative is to require every system to have an ever-growing set of old versions of the component. That way lies madness. >> 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? Well, that would be good, but what I was thinking of was "don't use Python at all". > 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? Sorry, "infrastructure" is overloaded in this discussion. I was referring here to Python, not to the packaging subsystem. > No packaging system, however good, is going to change the world. Exactly. > 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. Right... The packaging subsystem, no matter how good it is, cannot solve the really hard parts of the problem. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
