Sven Neumann <sven@xxxxxxxx> writes:
> > standard libray versioning scheme is to set soname to
> > lib<name>.<major> (library being named lib<name>.<major>.<minor>
> > on filesystem)
>
> Don't get confused by the numbers, libgimp-2.0 is the library name
> we've choosen. There is nothing wrong with that. It's just a name.
>
> > if the a branch of a library is not compatible with the previous
> > one, maintainer only has to bump its major. nothing more.
>
> That's exactly what we are doing. Nothing more. Please have a look
> at the versioning scheme I pointed you at. It does exactly what you
> are suggesting.
but it makes packaging harder for distros.
both debian and mandrake (and even redhat now due to gtk+-1.2 to
gtk+-2.x transition) use versionned packages for library (eg one can
install libfoo2-1.0.1 and libfoo3-1.1.9 at the same time)
this system works great for quite a number of libraries.
but for libraries that include their version number into their soname,
this makes packaging harder when one want to still be able to keep
several versions of the same library.
since the major is not anymore unique (eg gimp-2.0.23 will provide
libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from
gimp-1.3.23), we've to include version number into package name too.
eg: libgimp is named libgimp1.3_22-1.3.22-1mdk.i586.rpm on mandrake
and libgimp1.3_1.3.22-3_i386.deb on debian [1].
sadly, this is less readable.
this also pressure packages managers by increasing the ammount of
requires and provides (because libfoo<bar> provides libfoo = bar).
what's more development packages (aka headers, build infrastructure
such pkgconfig files) conflicts (different names due to version number
being included in package name).
this can be workarounded by not including the minor version number in
devel package name.
but there's also the problem that currently we also have to rebuild
dependant packages on each gimp release because major bumped on each
release (since lib major equals version number's minor) even if there
really wasn't any api change.
i usually advocate the "let bump the major lib" on api/abi change
because it enable to track common problems:
- undetected symbols mismatch that requires relinking because of abi
change when one lib as the same soname but one package requires the
foo version whereas another one requires bar version (both using the
same major) resulting in one of them being silently broken,
- undetected need for rebuild and patching on api/abi change,
- uneeded breakage in third party programs (though i personnaly do not
really care about it by myself, i do understand that it can annoy
non free software vendors)
i agree that you way works too and i agree the packaging issues may
not be strong enough so that you alter gimp library versionning
system.
note that you approach results in having several libgimp1.3.XYZ libs
installed at the same time when one update whereas there were no real
api change (easily "fixable" of course but ...).
[1] i provide gimp1.3 in contribs because so much people complain to
me about font issues with gimp-1.2.x
