[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pkg like shlibs

On Sun, Aug 27, 2006 at 05:21:50PM +1000, skaller wrote:
> I would like to install 'like shlibs'.
> When a shared library is installed, if the 'version'
> changes, the old shlib is not removed, because this would
> break already built binaries.
> Instead, a new shlib is simply added, and 'most recent'
> links are added.
> Other packages do this too, for example installing gcc
> doesn't clobber an old version of gcc, it adds a new
> set of components, and adjusts one link, 'gcc' to point
> to the most recent one. 
> With Felix I want to do this too. The basic install shouldn't
> clobber the old one. In this case the script 'flx' is the 
> thunk which is clobbered to point to the new install
> (but it can be told to point at any install with a switch
> or environment variable).
> However this means I can't install in places like:
> 	/usr/lib/felix
> but have to install in 
> 	/usr/lib/felix-1.1.2
> instead. However the package name is 'felix' .. 

You have to name the package felix-<abinumber> or something, just like gcc.

We already moved some this way with ocaml, who installs in
/usr/lib/ocaml/<version>, but didn't go the full way. There are two issues
remaining :

  1) binaries are not versioned. Upstream support for this is a bit fishy, and
  it would have represented lot of work.

  2) we decided to keep only a single ocaml non versioned package, in order to
  avoid issues with NEW and lag due to the ftp-masters overload.

Also, the alternatives mechanism is of interest to you, since it would allow
to set default symlinks, with the user being able to override them, altough it
doesn't do well with a set of binaries to such alternate.

> What's the best way to handle this?
> I think it is OK than man pages get clobbered 
> (man is too dumb to be extensible).

Well, you would not be able to install both packages simultaneously in this
case, so you need to add the proper conflicts.

> Also the 'doc base' can point at the most recent docs.
> The reason for all this is the same as for any system:
> ABI changes shouldn't break existing code or development
> efforts. 


> * ELF already handles this for shared libraries.
> * Ocaml provides no way to handle this properly.

ocaml in debian does have tools and infrastructure to handle this properly, as
defined in the ocaml policy, with the above caveats.

> * As of 1.1.2 Felix now handles this


Just a suggestion, i strongly encourage you to read the new maintainer manual
and the developer reference, as well as maybe reread a bit those older threads
here about those exact subjects.


Sven Luther

Reply to: