Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Emil Velikov]

On 10 July 2016 at 11:11, Jan Engelhardt <jengelh at inai.de> wrote:
>
> On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>>>
>>> First, what kind of parallel installability is sought?
>>>
>>> * just runtime
>>> * parallel development environment (like what e.g. libabw,
>>>   librevenge.. do)
>>
>>everything that is about libweston including development enviroment
>>has been my idea.
>>
>>> Few projects ever go to the length of making their /usr/include
>>> headers or .pc files coinstallable by including some version number in
>>> it.
>>
>>Is there any particular downside of going all the way?
>
> For example, if a program supports being built for gtk2 and gtk3,
> it can't simply do
> PKG_CHECK_MODULES([gtk], [gtk >= 2])
> because the developers chose to stick the version in the basename :-(
> Which means that someone has to do
> PKG_CHECK_EXISTS([gtk-2.0], [PKG_CHECK_MODULES([gtk], [gtk-2.0])], [
> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
> ...repeat the fun...
> ])]
>
Yes, it's one line of fun for each version that you want to be
compatible with. It's not ideal, but it's a price to pay, for keeping
things compatible/sane.

> Now with gtk it was not so much a problem (yet!) because there
> are only two different basenames in 15-or-so years.
> But if weston wants to go to 27 "soon" (...)
>
>>> >- MAJOR will start running like hell, we'll probably get to weston
>>> >  27.0.0 before it slows down, or whatever
>>>
>>> - if just parallel runtime is the goal: done deal, just bump
>>>   the SO/ABI version (libfoo.so.2, .so.3), no one cares about
>>>   how high they go
>>
>>We also have plugins and other stuff, to be scoped by installation
>>directory.
>>
>>Wouldn't that cause installations to have a libfoo.so symlink
>>without a version number? That we do not want, a too high risk of
>>pointing to a wrong version.
>
> The .so symlink is really only for /usr/bin/ld. It does not
> play a role for ld.so (ld-linux.so.*) and therefore won't
> interfere with plugins living in versioned directories.
> (Cf. libmirage from cdemu)
>
True, it won't interfere with plugins living in versionned
(sub)directories, since those are already linked against the correct
binary. The (main?) problem that Pekka is pointing out is that we
don't know which version we'll link against. Why you might ask - the
libfoo.so symlink may point to libfoo.so.2, libfoo.so.3 or
libfoo.so.X. Since we don't have (imho for a very good reason) control
which version of the said library we want to link against, we rely on
libfoo.so being correct.

I get the feeling that you have not read the following
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.

>>The point is, we need to define the libweston MAJOR to be used in
>>installations separately from the project MAJOR, even if they will
>>always match with releases, because they won't match during
>>development.
>>
>>That's probably the simplest solution for starters. We could add
>>configure.ac automation to use MAJOR+1 in the SONAME when project
>>MICRO >= 90, too. Or maybe that will be MINOR >= 90 once we get to
>>the habit of bumping MAJOR.
>
> Or you can just have two lines in configure.ac next to each other
> which will scream at you "update me in lockstep" everytime you look
> at them because you modify one of them.
>
> AC_INIT([libweston], [1.12.0])
> libweston_SONUM=3
> ->
> AC_INIT([libweston], [1.12.90])
> libweston_SONUM=27
>
This could also work, but Pekka's idea sounds more robust and simpler
in the long run. Add the logic once and don't bother checking/keeping
things in sync ;-)

Just my 2c, as they say.
Emil