J. Estes writes:
> I understand the need for http/https support in pkgadd, but the
> argument that static linking leads to multiple copies of software
> also occurs with dynamic linking, with bad results. As an example,
> the pkgadd in Solaris 10 is dependent specifically on version
> libopenssl.so.0.9.7..so, and the version of libgcc_s.so that comes
> with the included version of GCC. A user who might need to build or
> load a software package that uses a newer version of libopenssl.so,
> say v0.9.8a, and wants to use a newer version of GCC, and hence a
> newer version of libgcc_s.so now has multiple version of software on
> the system if /usr/sfw is on the system.
Yes. With decent engineering work, that shouldn't happen, but I agree
that software with incompatibilities across versions can cause that
problem.
I'm just saying that the problem is magnified when you use static
linking. Every bit of software in the system carries its own copy of
the menace.
> This facth leads to messy
> conflicts, for example, with pkgadd:
That's not true, unless you do something unfortunate, such as setting
LD_LIBRARY_PATH or overwriting installed software without doing a
regular upgrade or patch.
> a dynamically linked pkgadd requires libopenssl.so.0.9.7, and
> installing a newer version of libopenssl.so (e.g. 0.9.8a) to build
> other 3rd party software leads to linkage errors using pkgadd,
> because of unresolved symbols, unless v0.9.7g is first in the link
> path (this I have experienced first hand).
Did you have LD_LIBRARY_PATH set in your normal login environment?
Don't. If you can't get software linked correctly with -R for some
reason, then use crle(1) instead. LD_LIBRARY_PATH is a sledgehammer.
> One would be forced to accept the version of statically linked software, i.e.
> pkgadd, but it is part of the core O/S and it makes sense to include it.
> Static linking does provide freedom:
> specifically freedom from depedence on third party software for which the
> version included with the O/S causes linking conflicts, as in the example
> cited previously. This conflict does not occur if pkgadd is statically
> linked.
There's no such conflict, unless something bad (like LD_LIBRARY_PATH)
is done. Normal software should be linked using -R to set the search
path correctly, as /usr/sbin/pkgadd does.
> ** Also note that I am _not_ suggesting that all utilities should be
> statically linked, only those dependent on 3rd party software. **
I still disagree, and we have rather explicit and intentional
engineering rules against such practices.
> > The design issue is how to have a feature like this ("optional"
> > web-based package install) without making pkgadd
> > depend directly on the OpenSSL libraries. I think that there's
> > room for useful work in this area. It may be possible to
> > decouple these two components in such a way that the web
> > features are present only when the optional
> > SFW components are installed, rather than just simply
> > requiring them to be installed at all times.
>
> This is the crux of the current problem with Solaris 10: the
> /usr/sfw components are not optional. They are loaded without the
> user having any choice in the matter.
I think that's really a separate issue. Our installer should probably
provide more detailed options in selecting what software to include.
That's a much bigger project, though, than just decoupling pkgadd and
ssl.
--
James Carlson, KISS Network <[EMAIL PROTECTED]>
Sun Microsystems / 1 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
