Kristian Rink writes:
> Mauro Mozzarelli schrieb:
> > Please, could you expand on your statement? Why would it be a bad
> > idea? To me, it would solve most of the problems we have today with
> > OpenSolaris on having to create redundant sub-installations of most
> > of the operating system dependencies, only to install a package like,
> > for example, "mplayer" from blastwave.
> 
> How?

It wouldn't have any effect on that problem.

The blastwave problem is that the repository (in general; there are
exceptions) aims to be self-contained and to run on Solaris 8 and
higher.  That means that many packages declare a wealth of
dependencies, and those dependencies are to other blastwave packages
that carry the libraries needed.

In order to fix this "problem," someone would have to figure out a way
to make a blastwave package that depends optionally on either a
system-installed copy of the "foobar" library or, if that's not
available, a blastwave variant of "foobar."  Then you'd have to make
sure that it links to the right one at run time, and you'd have to
make sure all of the versioning lines up -- meaning that the blastwave
copy of "foobar" would likely be constrained to versions that happen
to be compatible with the system-supplied ones.

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.

Merely adopting RPM or any other random packaging technology won't fix
the dependencies that are built into the binaries that are being
delivered.  Packaging is just a container.

For me, the right solution is to throw more disk space at it.  Disk is
cheap, and a few gigs of disk for all that blastwave delivers is a
pittance.

-- 
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

Reply via email to