[csw-maintainers] Handling of devel package splits

[James Lee]

On 06/10/09, 12:55:05, Dagobert Michelsen <dam at opencsw.org> wrote regarding
Re: [csw-maintainers] Handling of devel package splits:

> > The only addition I have it to version runtimes as it means only one
> > version is needed at a time for a given depend.
> >
> > jpeg depends on jpeg7rt
> > jpeg7rt - latest runtime
> > jpeg62rt - legacy runtime
> >
> > packages depend on whichever rt version being used.

> I don't think this will work.

Don't think, watch the opposition.


>  It would mean that you know in advance
> which
> version is compatible to name it correctly, here you must know that
> jpeg62rt
> is the compatible version, and without naming it too strict like
> jpeg6203b2rt.

I know because of the SONAME.

Example of potential saving.

CSWlibicu 4.2.1,REV=2009.08.10

Package size:   14883205
installed size: 35943114

Contains libraries with 2 SONAMEs: .so.36 and .so.42

$ cat /opt/csw/lib/libicu*so.36.0 | wc -c
 12916776
$ cat /opt/csw/lib/libicu*so.42.1 | wc -c
 19310756

1 package uses .42 (CSWooocore), 2 use .36 (CSWtin, CSWx3270)

Each could use just the rt that it needs.

The best bit is when the 2 older packages are rebuilt to use the
newer rt the combined package does not need rebuilding with only
the used lib as the unused rt package can just be dropped.

Potential savings are massive, far greater than some x lib headers.

Package split:

libiuc42rt - the .so.42 runtime used by CSWooocore, CSWlibicu
libiuc36rt - the .so.36 runtime used by CSWtin, CSWx3270
libicu everything 4.2 except libiuc42rt


No user will ever install libicu, only developers.



> At the same time you want the name of the package to be as easy as
> possible
> which contradicts specific naming in advance.

> I have written the rationale for this in the Wiki at
>    <http://wiki.opencsw.org/packagesplits>

> Why are packages split?

> There are multiple reasons why packages are split:

I suppose two is "multiple"


> To minimize the size of the installed software, both in terms of
> megabytes and number of files

In the case of the x libs (where this started) only the run time is
installed for users so there are no extra development or documentation
bytes.

Minimising the number of package also has benefits.  Quicker install.
Shorter lists.  Easier management.

File storage is not that important.


> To have a clean installation of the software (no developer files on
> deployment machines)

man filesytem(5).  There is a handy established way of keeping the
system tidy.



Reasons not to split:

+ Many more packages to manage

+ No space saving when only runtimes used, which is in most cases.

+ It's a pain for the developer to know to install the -dev packages.
  Not all packages naturally have dev parts and it's not possible to
  tell if it's missing or never exists (oh great, lets have empty
  packages where none is needed to keep the system symmetric and avoid
  all confusion).

+ I always install "full" OS (because it's saves any effort when I
  later find something is missing) so there is no problem with finding
  headers on the system.

+ Solaris has lots of files that are never needed.  Doesn't make it
  right but the user tolerates it, assuming a true user even notices.

+ CSW wastes space in many ways, this isn't the most significant.
  Packages are about package deals and a one size fits all approach
  might be best, ie, the user accepts extra bytes in exchange for
  a shared system.

+ It's pissing me off.




James.