[OpenIndiana-discuss] Making OI Packages (part I)

[Richard L. Hamilton]

> I was talking binary compatibility, while it sounds like you're talking source
> compatibility.
> 
> If you can build a library with either Studio cc or gcc, then users of both
> can link their programs against it, you don't need to provide different
> versions for each compiler as you must do with C++.   (And technically it's
> worse with C++, since there's multiple versions of the ABI for each, but
> for now, I believe the C++98 standard version of each is currently the only
> one worth worrying about until the C++0x versions take hold, and the pre-98
> versions can be ignored.)

I'm talking about both, in this sense: some open source software
written in C++ will presumably only compile (without significant
changes) using the GNU compiler suite, because that software
depends on features not (compatibly) present in the Studio suite.

If that software depends on C++ libraries, then because
of the binary incompatibility between C++ APIs for gcc vs Studio,
that means all its C++ dependencies also have to be compiled with
gcc, even if one also has a Studio compatible version of them to
satisfy other needs.  That would be the case even if the library
source code was compatible with both compilers.

I guess the main thing I'm saying is that dependencies can get
ugly as it is (not that I know that it uses anything in C++, but
taking as an example pidgin, it links to over _50_ libraries!).

With such proliferation of libraries, and two different ABIs for
C++ libraries, I'd just about count on it that there are going
to be situations where one will need them compiled with both
compilers.  Or with multiple versions of a library to accomodate
apps with incompatible dependencies.  Or both.

To an end user, what makes a distro different from a disparate
collection of parts is that _everything_works_; all dependencies
have been resolved (while at the same time having only those
multiple versions or ABIs or whatever of dependencies as are needed).
Realizing also, that there's a definite choice to be made in terms
of being able to update individual apps relatively separately
vs having less versions of dependencies around.  Both can be
legitimate choices - smaller disk and memory footprint vs
greater freedom to keep apps current.

That means that some sort of _design_ and testing probably has to
apply to the distro as a whole, packaging has to correctly and
maintainably identify dependencies, etc.

Which is why all this talk like the ideal distro should match
Debian, Fedora, or Ubuntu's package count makes me crazy.
Better to prioritize and go for overall quality, IMO.  Get a good
handle on what it takes to do a really excellent job of integrating
packages (maintainably) before going crazy on making the number
look good.

Not only does that apply to the individual user, who doesn't want
to be be fixing things the distro creator should have done right.
It applies to enterprise level use as well, where updates may well
be automated, so there'd better be darn few surprises, or the
phone will ring off the hook when an update is pushed out.