[csw-maintainers] An idea for a shared libraries policy

Maciej (Matchek) Blizinski maciej at opencsw.org
Wed Sep 29 19:40:47 CEST 2010


No dia 29 de Setembro de 2010 09:32, Philip Brown <phil at bolthole.com> escreveu:
> On 9/28/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> No dia 28 de Setembro de 2010 10:57, Philip Brown <phil at bolthole.com>
>> escreveu:
>>>
>>> 2. where the name may not neccessarily imply, "hey this is a library".
>>
>> Can it ever not begin with "lib"?  I thought that when you link using
>> the -lfoo flag, the linker will only link with libfoo.so, nothing
>> else.  Hence, the file must be named libfoo, and so must the package.
>
> But there are other ways to use a dynamic object, other than linking with -lfoo.
> We have a plethora of such beasts.
> The related question would be whether it would be justified to ever
> create a separate package around them.
> Most of them are more the realm of dynamically loaded objects.
> An extreme case would be the gimp modules/plugins.
>
> Probably most of those things, arent versioned in the same way as
> regular shared libraries, so perhaps it is not an issue. But it still
> bears consideration.

Do we have instances in which we package multiple version of the same
dynamically loaded object into one package?  I think not, but if we
had, they could be separated as well.

>>>> I could write a checkpkg test: if there's a shared in /opt/csw/lib
>>>> (including ISA subdirectories), and has a SONAME, the pkgname must
>>>> conform to:
>>>>
>>>> CSWlibrarynamesonameversion or CSWlibraryname-sonameversion
>
> What about if there are multiple objects in the package?

The idea is to not have multiple objects in one package.  It's best of
the granularity corresponds to the chunks in which we'll phase out
shared libraries.  If there are multiple libraries that are to be
phased out together, they could live in one package.  However, this
might be hard to predict, so it's safer to have each object in a
separate package.

There's one more thing: symlinks.  With two versions of one library,
we might have two packages:

CSWlibfoo0:
/opt/csw/lib/libfoo.so → libfoo.so.0
/opt/csw/lib/libfoo.so.0 → libfoo.so.0.0
/opt/csw/lib/libfoo.so.0.0 → /opt/csw/lib/libfoo.so.0.0.1
/opt/csw/lib/libfoo.so.0.0.1  (actual data)

CSWlibfoo1:
/opt/csw/lib/libfoo.so → libfoo.so.1
/opt/csw/lib/libfoo.so.1 → libfoo.so.1.0
/opt/csw/lib/libfoo.so.1.0 → /opt/csw/lib/libfoo.so.1.0.1
/opt/csw/lib/libfoo.so.1.0.1  (actual data)

With this layout, we end up with two instances of
/opt/csw/lib/libfoo.so.  This file needs to be in a different package,
I'd say in the same package as the header files.  It could be a
*-devel package or the main package.  The corrected layout:

CSWlibfoo-devel:
/opt/csw/include/foo.h
/opt/csw/lib/libfoo.so → libfoo.so.1

CSWlibfoo0:
/opt/csw/lib/libfoo.so.0 → libfoo.so.0.0
/opt/csw/lib/libfoo.so.0.0 → /opt/csw/lib/libfoo.so.0.0.1
/opt/csw/lib/libfoo.so.0.0.1  (actual data)

CSWlibfoo1:
/opt/csw/lib/libfoo.so.1 → libfoo.so.1.0
/opt/csw/lib/libfoo.so.1.0 → /opt/csw/lib/libfoo.so.1.0.1
/opt/csw/lib/libfoo.so.1.0.1  (actual data)


More information about the maintainers mailing list