xRe: [ecasound] embedding interface version numbers in library names

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: xRe: [ecasound] embedding interface version numbers in library names
From: Kai Vehmanen (k_AT_eca.cx)
Date: Sun Apr 28 2002 - 00:01:09 EEST


On Wed, 24 Apr 2002, S. Massy wrote:

> Not only do I agree with this scheme but I also suggest extending it to
> executables as well, just like with Debian.

I'd really like to avoid making any user-visible changes. And changing the
executable names would be one.

And anyway, unlike libraries, it's quite easy to handle multiple versions
of executables. You can...:

- install multiple versions of ecasound to different directories
   - rpm: rpm -iv --prefix=~/apps/ecasound-x.y.z ecasound-x.y.z-1.i386.rpm
   - source: ./configure --prefix=~/apps/ecasound-x.y.z
- use symbolic links to select the default version and for
  creating aliases
   - ln -s ~/apps/ecasound-x.y.z/bin /usr/local/bin/ecasound
   - ln -s ~/apps/ecasound-z.y.z/bin /usr/local/bin/ecasound-x.y.z
- use autoconf's existing versioning features to automatically
  renamed the executables
   - cd ecasound-x.y.z
   - ./configure --program-suffix=_x.y.z

As for library versioning, I've now implemented the new library versioning
scheme. I'll put it in CVS later today. Explicit versioning is now
used in:

- library names
   - libecasound8.so, libecasound8_debug.so, libkvutils3.so, etc
- library config files
   - libecasound8-config, libecasoundc2-config, etc
- plugin directories
   - new default: {prefix}/lib/libecasoundX-plugins

I've also rewritten ecasound's rpm-spec file. It now creates:

ecasound-x.y.z
pyecasound-x.y.z
libecasoundX-x.y.z
libecasoundX-plugins-x.y.z
libecasoundcY-x.y.x
libkvutilsZ-x.y.z

The first two are not versioned (you can only have one version of the
package installed at a time). The other packages on the other hand are
versioned and you can freely have as many different packages installed at
the same time as you want.

One downside of this approach is that users need to download multiple
files to install ecasound. To somewhat help the situation I didn't
specify separate -devel packages for the libs.

> So when installing, say ecasound v2.1dev8, you'd have the libraries
> with their respective major versions appended to their names, but the
> executable installed would be called ecasound-2.1dev8. The
> /usr/local/bin/ecasound file would be a symlink to your favourite
> version of ecasound. That would be a great way to have several versions
> of ecasound live in simple harmony together.

To do this, we'd need to:

- have a custom post-install script that checks whether any
  ecasound versions is already installed, and if not, make
  the symbolic link
- add version numbers to all man-pages, resource files and
  directories

And to make rpm happy, we'd need to have different package names for
different ecasound versions. This would make it impossible to upgrade
ecasound, because all packages would have separate names. Unlike
libraries, where interface versions change only between big releases,
client apps change all the time.

-- 
 http://www.eca.cx
 Audio software for Linux!

-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Apr 27 2002 - 23:46:52 EEST