On Tue, Mar 15, 2005 at 02:40:25PM -0700, Warren Young wrote:
> Chris Frey wrote:
> >I find it confusing that the major version of the library is 4,
> There's precedent. The MySQL C API library I use is version 12, for
Ok, that explains why this scheme was chosen.
> >doesn't tell the administrator anything useful.
> Under RPM, you can say 'rpm -qf /usr/lib/libmysqlpp.so.4' and get
> 'mysql++-1.7.31' back. Other package systems I've used have a way to
> ask what package owns a particular file, too.
I knew that, but I still like the libraries themselves to have that info.
An entire package management system shouldn't be required for such
basic info. :-)
> >Multiple versions at once is an administration feature, and would make
> >a lot of sense when 1.8, 1.9, etc are released so that stable and dev
> >versions could be run at the same time.
> I'm uncomfortable going backwards in version numbers at this point. If
> versions 4 and 1.8 are installed, g++ will try to link against version 4
> when building the binary.
g++ has no logic in it for version numbers. It doesn't know the
difference between 4 and 1.8. It looks at the libmysqlpp.so link,
and uses whatever that points to.
So the administrator or package system chooses which lib is used for
development (and the package management system (RPM, etc) should "know"
which version number is newer and set it appropriately).
As a test, to make sure I still understood this correctly :-) I deleted
my /usr/lib/libmysqlpp.so link, and reran ldconfig. The link was not
recreated, which indicates that it is governed by the installation,
and/or the administrator. And really, only the admin/package system knows
where this link should point.
ldconfig did know how to rebuild libmysqlpp.so.4 to make it point to
libmysqlpp.4.0.0, so perhaps my "1.8" idea needs some more thought,
but g++ is not a reason in itself to avoid moving from 4 to 1.8.
After reading part of the shared library howto, I withdraw my
"1.8" suggestion, since it seems it would break conventions. ldconfig
doesn't know how to deal with it automatically, so we'd have to do it
> In any case, I'm not really asking about having both 1.8 vs. 1.9
> libraries installed. Presumably there's an ABI change between those
> two, so under the current scheme they'd get different library names, so
> you could still install the new one without needing to relink old binaries.
Different name, as in "libmysqlpp-dev"? Or did you mean a new number, like 5?
> Ignoring the v4 vs. v1.x issue, what I'm really asking is, is there any
> point in having both libmysqlpp.so.1.7.31 and libmysqlpp.so.1.7.32
> installed? That's the situation that causes overhead for each release,
> and which has no value unless you make the effort to link against a
> specific point release. I can make libtool use these version numbers,
> but unless a program is linked specifically to one point release,
> there's little point in making the effort.
I don't think there's any need for it in the current stable release, but
I think now (the next dev cycle) is the time to do it before lib numbers
rise any higher and pollute possible namespace.
The '4' looks hideous to me, since it conveys no meaning, but the
practicalities of shared library management are conspiring against me,
and it does make sense from the ABI viewpoint.
Conventions indicate that the version numbers stand for:
<ABI version>.<minor version>.<release count>
libmysqlpp.so -> libmysqlpp.so.1
libmysqlpp.so.1 -> libmysqlpp.so.1.7.32
libmysqlpp1.so -> libmysqlpp1.so.7
libmysqlpp1.so.7 -> libmysqlpp1.so.7.32
libmysqlpp.so -> libmysqlpp.so.4
libmysqlpp.so.4 -> libmysqlpp.4.0.0
If the '1' in 1.7.32 represented the stable ABI, this would make
a lot of sense for library versioning. It would put a significant
freeze on what changes are allowed in stable releases though.
I like option #1 or #2.
This gives developers and admins full flexibility in the number and variety
of mysql++ versions on a system, and would hopefully reduce the number of
segfaults and library problems people have. (doubtful, but I hope)
Plus, it provides a clear upgrade versioning path. With '4', I don't know
what comes next for the dev cycle. 5? 6? Are ABI changes allowed in
the stable release? If so, does it become 5 if dev is already using it?
> >It's all just symlinks anyway:
> Yes, but those symlinks are maintained by ldconfig on a Linux system. I
> have no control over them. I could make my own symlinks, but then I'm
> fighting the system.
As shown above, ldconfig only updates the soname (*.so.#). The dev
links (*.so) are controlled by the install process (which in mysql++'s case,
it's controlled by the Makefiles). There could be special logic in the
RPM to handle arbitration if needed.
> >Perhaps a jump in version to an even number for the next stable release
> >would make things look more like the kernel. :-)
> ...except that they just abandoned the whole even/odd thing. :)
As you can tell, I like logical version numbers! :-) It's a sad situation
in kernel land.
Thanks for the patience in reading all this,