> The reason they are required is that pkgadd natively
> supports installing software via http: and https: with the "-d
> device" option. You can download and install signed
> packages over the web. This is part of the functionality
> required by the existing Solaris 10 "WAN boot" feature.
>
> The architectural issue is that we do not want to
> have multiple copies of the same software in the system.
> Thus, static linking for this sort of thing is just not allowed,
> and that can't be one of the solutions. Besides just the
> software-bloat problem, static linking is
> bad engineering: it forces users to patch the same
> bug (or vulnerability) multiple times, and opens the door for
> divergence.
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. This facth leads to messy conflicts, for example, with
pkgadd:
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).
As to the issue of code bloat, /usr/sfw is _huge_.
> Indeed, static linking provides you with *NO* freedom at
> all. You're forced to take the statically-linked software, even
> if you've somehow decided you don't want it. It'd be a step
> in the opposite direction.
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.
** Also note that I am _not_ suggesting that all utilities should be statically
linked, only those dependent on 3rd party software. **
> 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.
> Static linking, though, isn't the answer.
> --
> James Carlson, KISS Network
> <[EMAIL PROTECTED]>
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
