[csw-maintainers] Handling of devel package splits

Dagobert Michelsen dam at opencsw.org
Tue Oct 6 16:47:27 CEST 2009


Hi James,

Am 06.10.2009 um 16:03 schrieb 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.

Ok, that means you look what is linked against and then decide
how the rt is named?

> 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.

Separating filesystems still gets them inside the tree.

> 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.

Added to the wiki for further discussion.

> + It's pissing me off.

Not added to the wiki.


Best regards

   -- Dago



More information about the maintainers mailing list