Moinak Ghosh writes: > On Fri, Jun 27, 2008 at 7:39 PM, James Carlson <[EMAIL PROTECTED]> wrote: > > No matter _what_ packaging mechanism is used, that's a tall order. I > > certainly don't blame anyone for not tackling it. I suspect it might > > not be fixable in any real sense at all. > > It appears to be fixable. > RPM does have features that make this possible via the Provides > clause.
No "Provides" clause is going to make the version skew or library search path problems go away. It's an extremely handy mechanism for the few cases where there are alternative and mutually incompatible implementations of a feature (say, sendmail and postfix), but I don't think it's a complete solution for handling the library explosion problem. > A package like say SUNWgnome-base-libs can mention: I provide > libpango-version, libgtk-version, libglib-version and so on. Another > package > needing those libs can say: I require libpango, version >= <version>, > libglib, version >= <version> and so on. The package system evaluates > these dynamically and figures out appropriate dependencies without > having to explicitly bind to package names from specific repositories. > I find this feature extremely powerful and generic. ... and the result is that (in the long term) you end up pulling either per-repository libraries, as these versions skew apart and separate repository maintainers make their own independent upgrade plans, or (worse) you end up with repositories that have multiple library versions contained within. It's a pretty toxic situation, as nothing in the run-time linking system knows whether two libraries can safely be loaded into the same address space or not. (For background, ask about the libresolv.so.[12] fiasco some time ...) > This does not mean that I am suggesting RPM for OpenSolaris. However > this is something that Pkg should have looked at IMHO. I did mention > this time and again in various contexts. I don't think they've forgotten it. But I also don't think that switching to RPM would bring with it any substantial magic. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
