Re: parallel installation issues for gstreamer

[Havoc Pennington <hp redhat com>]

On Sun, Dec 08, 2002 at 02:46:28PM +0100, Thomas Vander Stichele wrote: 
> The theoretical goal is to make all versions with different major/minor 
> before 1.0 parallel-installable.  We'll be doing minor even = stable 
> releases from now on, so this basically applies to the "stable" versions 
> gstreamer-0.6 and gstreamer-0.8, and the development versions for those, 
> gstreamer-0.5 and gstreamer-0.7

FWIW this is more than we do for any other lib; for other libs, we
only bother with parallel install a) if it's a platform lib and b) for
each stable release.

It sounds a bit like you're trying to support the API/ABI of frequent
beta releases, while also claiming you don't support it - I wonder if
you aren't better off just stamping something 1.0, branching it,
supporting it for real, and then moving on to 2.0. GTK 1.0 sucked, all
1.0 sucks, don't be shy. ;-) By "support" I just mean critical fixes
are backported and there's a release from time to time, until you have
a new stable release and most apps stop using the old one.

There's a lot of value to only releasing a new API/ABI intended for
wide use every year or so. A new parallel-installable API/ABI
iteration that a lot of packages are using every few months would
probably be pretty annoying. Plus in practice you won't be able to do
a lot of backported fixes or releases because you have too many
"stable branches" and so you'll be forcing everyong to upgrade to new
versions all the time anyhow. And won't have time to QA the parallel
installation properly.

GTK2 has taken at least a year just to get wide use...

> a) gst-plugins installs a schema.  I can do three things:
>    - leave the path in gconf to /system/gstreamer and keep the filename
>      gstreamer.schemas, making it not parallel-installable
>    - change both the filename and the path to gstreamer-0.5
>    - make a separate package ONLY for the schema file, so that this
>      too can be reused among different incompatible versions.
> 
>    I prefer the second option.  The first would nullify the work I did
>    already to make it fully parallel-installable, which is a worthwhile 
>    goal.  The third one is overkill IMO.

If the keys are the same, I think it's pretty annoying to change their
names all the time. Consider the plight of the poor sysadmin or prefs
dialog author. Or just users that would rather not keep losing their
settings.

The first option basically forces distributions to do the last option 
(put the .schemas somewhere shared).

The last option is workable, if you follow the rule you should follow
that anytime a key changes incompatibly it is renamed. In general, it
should always be possible to use the same gconf database with both
GNOME 2 and GNOME 2.4 and GNOME 3, for example. Though a tiny package
containing only one schemas file is surely a bit annoying too.

The first option is pretty manageable for distributions if the stable
releases are infrequent (year, not months).

> b) gst-element-check.m4 being installed as gst-element-check-0.5.m4
>    this is an m4 to check if a plug-in is available.  It seems stupid to
>    version the filename only so it can be parallel installable, but I
>    see no cleaner solution.
>    Also, I'm not quite sure how aclocal behaves when two different files
>    provide the same macro.  Does it use either one randomly or complain
>    spectacularly ?

Older aclocal versions would complain and die, newer ones pick
something randomly but still complain. You really need to rename the
.m4 macro itself.

> c) is it ok to "not care" about binaries and man pages for them, since
>    it's stupid to version them and since they can be moved to a separate
>    package that would work with both installs ?

As long as they work with all possible versions of the library, they
don't have to be versioned. This means you have to permanently lock
down the interface between the binaries and the lib, though, whatever
that interface may be. If the binaries manipulate files for example,
you have to lock down that file format.

Havoc