gnustep-dev
[Top][All Lists]
Advanced

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

Re: [PATCH] Framework shlib versioning


From: Nicola Pero
Subject: Re: [PATCH] Framework shlib versioning
Date: Fri, 16 Jan 2004 11:40:33 +0000 (GMT)

> > Thanks for the explanation.  Interesting!  It probably needs more work
> > then - your point is very good, if we could implement so that it works
> > as you say and still it is an instance variable, that would be the best
> > thing. :-)
> 
> As an instance variable, it should be shorter, so you can give make the
> variable on the command line.

Ok
 

> > I think that a framework should have a single version string, so that
> > you know that libMyFramework.so.1.4.5 is using the resources in
> > Versions/1.4.5/Resources (or, if you prefer letters or a general version
> > string, libMyFramework.so.C is using Versions/C/Resources).
> > 
> > Otherwise it'd be a bit difficult (impossible ?) to match resources with
> > the shared libraries.
> > 
> > For this reason, I'd like to unify VERSION and CURRENT_VERSION_NAME
> > which are currently separated.
> 
> Hmm, perhaps they should be kept separate. The code version and the
> interface version are different things, even if GNUstep revs the version
> with every release (usually considered to be a bad idea).

Hmmm, yes, but this is a different difference :-)

Libraries already have a xxx_SOVERSION variable, which is different from
xxx_VERSION, and it's automatically generated from the version but you can
change it (normally if version is 1.4.5, soversion is 1, so that the
dynamic linker will consider all versions 1.x.y as binary compatible;  
you can change this scheme to whatever you want, a common one for example
is to use version 1.4.5 and soversion 1.4, so that only versions 1.4.x are
considered binary compatible, but 1.5.2 is not compatible with 1.4.3).

So I quite like your suggestions, where xxx_INTERFACE_VERSION is just a
new name for xxx_SOVERSION (and now available to frameworks too, which
would be good),

> How about:
> 
> _VERSION for the version of the package (in the info plist, if any),
> defaulting to 1.0.0 or even 0.0.1
> 
> _INTERFACE_VERSION (libraries and frameworks), for the version of the
> interface that the shared object and its associated resources refer to.
> 
> For libraries -- is the string used to form the .so version/soname, and
> nothing else.
> For frameworks -- used for .so version/soname and the name of the
> Versions/(foo) directory. If not present, its value is taken from _VERSION.
> As a convenience, a symlink with the value of _VERSION could be installed
> pointing to the interface version's directory (if _VERSION and
> _INTERFACE_VERSION are different).

but shouldn't the framework's Versions/ directory use the full version ?

You could have framework version 1.6.5 and version 1.6.6 which have the
same API, are binary compatible, and they only differ because an image
which was broken (wrong format or truncated or bad depth or in the wrong
directory) in 1.6.5 has been fixed (or renamed?) in 1.6.6.

The frameworks are in all senses compatible, and 1.6.6 is just a bug fix
of 1.6.5 where some resources have been fixed/renamed/moved/added/changed
(with concurrent updates in the code internals).  Because of the
difference in the resources (which might be internal to the frameworks),
1.6.5 might not be able to run using 1.6.6's resources.  So if you want to
have both of them in your machine (maybe you've got 1.6.5 installed and
are working on 1.6.6 so you want to install and test 1.6.6 but want to be
able to easily get back to 1.6.5 by restoring a symlink), they need to
have different resource directories.

They need to have a separate Versions/ directory, yet they have the same
"interface version".

This is why I'd recommend that every framework version has different
resources, so that the Versions/ directory name should be generated from 
the VERSION variable (which is supposed to change with every single public 
release).

If you consider that some of the resources can be considered part of the
framework's internal implementation, every release should be able to have
its own internal implementation even if they differ in the interface
version.

But with this small change, I quite like your suggestions.

 
> _DEPLOYABLE (frameworks and potentially libraries), to supply a decision to
> update symbolic links and, for libraries, headers. After all, it is
> reasonable to install an older version to satisfy a binary's dependencies or
> for other purposes. With the current setup if you install an older version,
> it will overwrite the symbolic link and the headers...oops, now you have to
> reinstall the newer version to get your system back to normal. Obviously,
> this should default to "yes". :)

I like the idea of _DEPLOY_WITH_CURRENT_VERSION renamed and used
consistently by both libraries and frameworks.  Very nice.  We just need
to find a good name :-)

I'm not totally convinced by _DEPLOYABLE - but I agree it's short and
being short is nice, which makes it better than
_DEPLOY_WITH_CURRENT_VERSION (even if this is a bit more expressive).  If
we don't find anything better, I suppose we can use _DEPLOYABLE.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]