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

[Maciej (Matchek) Blizinski]

Hello maintainers,

This is an idea for packaging of shared libraries which simplifies the
life cycle of a shared library, from the introduction to the removal
from the catalog.

Let's consider libfoo.so.1.  Instead of putting it into CSWlibfoo, we
put libfoo.so.1 into CSWlibfoo1.  When libfoo.so.2 comes along, we
package it into CSWlibfoo2.  This way, there's no need to do the whole
dance with shared libraries crammed into a single package.  All
software that depends on libfoo.so.1, depends on CSWlibfoo1 only.
Once dependent packages get recompiled against libfoo.so.2, they stop
depending on CSWlibfoo1 and start to depend on CSWlibfoo2.  Once
nothing depends on CSWlibfoo1 any more, the package is safe to remove
from the catalog.  It's also easy to check from the package database.

Transition from the current state is easy:

Before:
CSWlibfoo (libfoo.so.1)

After:
CSWlibfoo (empty) → CSWlibfoo1 (libfoo.so.1)

For an existing more complex package, with already existing two
versions of a library:

Before:
CSWlibfoo (libfoo.so.1, libfoo.so.2)

After:
CSWlibfoo (empty) → CSWlibfoo1 (libfoo.so.1)
CSWlibfoo (empty) → CSWlibfoo2 (libfoo.so.2)

With time, other packages start depending on CSWlibfoo2 and once all
dependencies on CSWlibfoo are gone, it's safe to remove.

Most of the benefit would come for the typical libraries such as neon,
libxml, which mostly contain just one library file (currently,
potentially in several versions).  It would also work well for
packages that change the sonames in a synchronous manner. If there is
a single piece of software that provides multiple shared libraries and
changes sonames at different times, we'd need to either create one
package per one shared library, or do what we do now, which is
providing all libraries in a single package.

There's one more benefit I can see: annoying unfixable legacy
libraries, e.g. with libraries with bad content.  Instead of having to
push a smelly content through our validation, we could separate out
the smelly stuff, push it once and not update it any more. For
example:

Before:
CSWpython (libpython2.5.so, libpython2.6.so)

After:
CSWpython (no shared libs) → CSWlibpython25 (libpython2.5.so)
CSWpython (no shared libs) → CSWlibpython26 (libpython2.6.so)

Once Python 3.1 becomes the new hotness and CSWlibpython3.1 comes
along, CSWlibpython2.5 and CSWlibpython2.6 would remain without
updates.

To sum up:

Advantages:
- easy and complete lifecycle of shared libraries
- phasing out of shared libraries can become part of standard catalog
update procedures
- simpler packages, simpler builds (no need for version modulations
and complex merges, good for new maintainers)
- isolation of old cruft
- no constant re-pushing of files that aren't updated any more
- more packages overall (good for stats!); at the same time, number of
packages released per software upgrade remains the same.  If there
was, say 4 packages to release with each Python update, it remains 4
per release.  There will be just one new package.

Disadvantages:
- maintainers need to make more decisions when packaging
- there's some amount of work to be done to do the transition, such as
creation of new packages and dependencies

I can't really think of any significant issues here.  It's basically a
slight increase in granularity, based on sonames.

Thoughts?