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

[Maciej (Matchek) Blizinski]

No dia 29 de Setembro de 2010 11:47, Philip Brown <phil at bolthole.com> escreveu:
>>> 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 are some things that conceptually should always be grouped together.
>
> For example:
> atspi
> /opt/csw/lib/libcspi.so.0.10.11
>  /opt/csw/lib/libloginhelper.so.0.0.0
>  /opt/csw/lib/libspi.so.0.10.11
>
> augeas
>  /opt/csw/lib/libaugeas.so.0.10.1
>  /opt/csw/lib/libfa.so.1.3.0
>
> boost_rt
>  (a BUNCH)
>
> fltk
>  /opt/csw/lib/libfltk.so.1.1
>  /opt/csw/lib/libfltk_forms.so.1.1
>  /opt/csw/lib/libfltk_gl.so.1.1
>  /opt/csw/lib/libfltk_images.so.1.1
>
> It would arguably be a mistake, to get into a packaging scheme which
> might allow some of these to accidentally get out of sync with one
> another.

Does the concept of being out of sync apply to separate packages?
This would be an example of an out-of-sync collection:

CSWlibfoo0:
/opt/csw/lib/libfoo.so.0
/opt/csw/lib/libfoo_bar.so.1
/opt/csw/lib/libfoo_baz.so.0

If you had them packaged as follows, you couldn't call them as being
out-of-sync.

CSWlibfoo0:
/opt/csw/lib/libfoo.so.0

CSWlibfoo-bar1:
/opt/csw/lib/libfoo_bar.so.1

CSWlibfoo-baz0:
/opt/csw/lib/libfoo_baz.so.0

Each dependent package would refer to the exact shared library it uses.

Boost library package is a collection of functionally unrelated shared
libraries, I think it makes sense to split them out: why would
download all of them if you only needed one?

The general point stands, that there are situations in which it makes
sense to group shared libraries together.  The deciding factor should
be the phasing out of the libraries: if we expect to remove them
together, we can package them together.

>From the checkpkg development point of view, it's best to provide a
test that suggests the right thing as often as possible.  Using
heuristics is alright, if they have good enough hit rate.  The base
rule is: "If a package contains a shared library, the package must be
named in such and such way."  This rule can be extended to allow
exceptions such as using the longest common substring, or something
similar.  I doesn't need to cover 100% cases, but the more, the
better.

> Ideally, in my opinion, they should remain as part of a single unified
> runtime package.

Did I already say that I consider the "runtime" word a misleading one
in this context?  Shared libraries are runtime files, but not all
runtime files are shared libraries.  For example, a Python "runtime"
package would need to include the interpreter.  However, libpython26
package doesn't suggest that "it's what you need to run Python
programs".  But this is another discussion; we could fork this thread
if anyone feels like pursuing that topic.

>> CSWlibfoo-devel:
>> /opt/csw/include/foo.h
>> /opt/csw/lib/libfoo.so → libfoo.so.1
>
> I agree, libxxx.so symlinks belong in devel packages. If you split out
> a runtime, you dont need the libxxx.so symlink.
> (but that's what we do right now already, I think. We just ship the
> "real" file, with no symlinks, in our "rt" packages)

The file with the data is usually named ${soname}.x.y, which will not
be enough for runtime linker which looks specifically for ${soname}, I
believe the library (or soname-providing) package should include all
three to be fully functional:

${soname} → ${soname}.x
${soname}.x → ${soname}.x.y
${soname}.x.y (data)

> Random comment: I think that libraries with SONAMEs that include minor
> revs, are more likely to fall prey to the need for splitting out.
> In contrast, libraries that have ONLY a major rev:  "libxxx.so.1" -
> tend to play nicely and respect compatibility between revs very well.
> (and by implication, will probably not need fancy sub-packages).   So
> you might go easy on the checkpkg checks, in those cases.

You mean, these where the soname has the form of libfoo.so.1.2?  I
think we best follow what linker does, which is the soname.

Roger wrote:
>> (...) CSWlibapr10 or CSWlibapr-10, (...)
> Shouldn't that be CSWlibapr1-0?
> Or what should you name the package when libapr-1.so.10.0.0 get released?

libapr-1.so.10.0.0 would be... let's run my current algorithm... here it is:

pkgname: ['CSWlibapr-110', 'CSWlibapr-1-10']
catalogname: ['libapr_110', 'libapr_1_10']

The policy would be: take the former, but if it's confusing, take the
latter.  I'd vote for CSWlibapr-1-10 + libapr_1_10.