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

[Alan Coopersmith]

I can't answer what rules OpenIndiana will enforce for it's packages, but
I can provide background on what Sun/OpenSolaris did and Oracle is doing
in the packages that OpenIndiana gets from OpenSolaris.

Søren Krarup Olesen wrote:
> 1) Some packages are named sunw...followed by a name. What does that
> really mean? sun is referring to Sun obviously but what about the 'w'?

The Solaris SVR4 package naming convention was to use the stock ticker symbol
of the company who made them.   Sun's stock ticker for most of it's life was
"SUNW" (I believe the W was for Workstations, it's primary product at the time
the stock first went on sale).

That naming convention was phased out with IPS - there should only be two SUNW*
package names left, and those will go away (at least in Oracle's releases) once
a few other things that directly depend on the old names are fixed up.

The mapping of old names to new names is at:
http://hub.opensolaris.org/bin/view/Project+indiana/Renamed+Packages+in+Build+133

> 2) How do we differ between run-time libs and development "libs" (the
> latter typically just a single .h file) when it comes to *naming*?
> Under Linux/Debian it was simple, e.g.: bananasplit.deb and bananasplit
> dev.deb...

OpenSolaris is moving away from splitting runtime & development packages.
The long term goal is to have them all combined and use the IPS "facets"
mechanism to allow sysadmins to chose to install or not install the docs
& development bits:
   http://src.opensolaris.org/source/xref/pkg/gate/doc/facets.txt

The X11 packages are the first to fully adopt this faceting, others are
working on it.

> 3) Must I in a compiled package include GNU license + source or will
> the binaries suffice?

Except for some historical artifacts, OpenSolaris does not provide GPL
licensed sources in packages in the repository, but instead provides those
as separate downloads/scm repos on opensolaris.org or on request.

> 4) Must I provide compiled packages with both gcc and CC, is there some
> kind of preference? And what names should be used?

For C language binaries, gcc & Studio cc are ABI compatible, so providing
both is a waste of time.   For C++, they are not compatible, so if you
must provide a C++ library that others will link against, you either provide
both or force a choice of compiler on everyone using your library.

> 5) Same as 4) only how to differ between 32 bits and 64 bits. And
> again...the naming question.

The OpenSolaris convention is to put both in the same package.   As for when
to include what types, the rules are a bit more complex, and there's always
exceptions, plus they change as the world evolves (for instance Solaris 10
dropped the 32-bit SPARC kernel, added the 64-bit x86 kernel).

The rough/basic rules OpenSolaris uses are:

 - libraries containing public API's (those you expect others to link their
   software against) should be provided in both 32-bit & 64-bit.

 - drivers & kernel modules should be provided in sets matching the kernels
   provided (right now, 64-bit on SPARC, 32-bit & 64-bit on x86) unless the
   hardware involved is not commonly found on machines with that type of CPU.
   For instance, many ancient drivers for hardware sold in the 90's don't have
   64-bit x86 drivers, because those devices wouldn't be found in a modern
   64-bit x86 computer unless someone was being very perverse.

 - Programs should be provided in 32-bit on x86, so they can run on all
   supported platforms.  A 64-bit version may additionally be delivered if
   it provides better performance or > 4gb memory may be needed.
   On SPARC, they may be 32-bit or 64-bit depending on the performance
   & capabilities required.

   Programs that poke into kernel structures, like ps, are usually provided
   in the same set of wordsizes as the kernels, so they can run the matching
   binary and not have to translate structures.

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System