On Mon, Jun 16, 2008 at 11:06:20PM -0700, Jordan Brown wrote: > 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.
That, I agree with. My concern is the amount of things we would need to compromise on to achieve this ideal. If it means not shipping applications people use, it is too much of a compromise, IMO. >>> 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? Sure. The basic system needs to be simple with the number of alternatives stripped down and conflicting choices kept to a minimum. Both OpenSolaris 2008.05 and just about every Ubuntu release do a great job of this. And this is sufficient for most users. However, the problem with a packaging system which does not accommodate conflicting releases of packages is that it would end up keeping some applications out, and consequently their users. >> 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 :-) That was a trap, then! :) Sure, I get your point about resource conflicts and I think we are on the same page in considering this a configuration problem rather than a packaging one. I think I see what you are getting at -- that everything should work out of the box and if there could be a conflict the maintainers should essentially exercise veto powers and pick one alternative. I totally agree with this. What I'm actually concerned about here is the packaging system *mandating* this and not being able to accommodate conflicting package versions at all. That, IMO, is a serious limitation. >>> 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. Very true (sigh!), but I don't see any practical alternatives. Your basic install would still probably not be too messy since the distribution gets to pick the components, but users have differing needs and some of those needs are going to eventually end up in ugly, complicated dependencies. >>> 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". Ouch! That's even more extreme?! Or do you means just not use Python for IPS? Even that is extreme IMO, and does not address the larger problem. Conflicting needs for Python versions is going to show up eventually. And what about the other packages? Like I said, Gentoo lists over 700 which see the need for "slots". (Well, maybe they over-use it a bit because the slot mechanism works so well, but still...) >> 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. Ah, okay. But still, not having a Python or even just shipping one version of Python seems waaay too extreme to me. It might work for the average Joe user, but power users are not going to appreciate it. And we need to attract power users for the community to succeed. Just end-users is not going to cut it. >> 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. Okay. But at least if we can get it to lay down the bits for conflicting package versions, users would be better off than before. The alternative (since not running the application at all or switching to a different one would not always be an acceptable solution) would be for users to compile/install application outside of the packaging system -- a return to the bad ol' days of handling dependencies by hand. Venky. -- One hundred thousand lemmings can't be wrong. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
