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

[Quentin Glidic]

On 10/07/2016 12:11, Jan Engelhardt 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...
> ])]
>
> 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" (...)

If we install only one .pc file:
- You cannot develop against an old version. And that means older 
version *than your distribution libweston*. Or we add the burden or 
developer to build older versions in their own environment, messing with 
PKG_CONFIG_PATH and stuff.
- Users won’t be able to build your project once you hit an API removal.

If libweston goes fast enough, compositor projects will just skip a few 
versions here and then, and eventually drop (some) old versions support, 
so the configure.ac check will not grow like crazy.

There are two kind of distributions: rolling release and versioned release.
The former will just include whatever versions are needed by compositor 
projects.
The latter will mandate some versions that compositors will have to 
support to be in these distributions. If there are enough users, 
distributions will probably patch them to support the shipped libweston 
version anyway.


>>>> - 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)

The versionless .so goes with versionless .pc. If ld cannot pick the .so 
you expect, things will explode.

As for plugins, the concern was for loading the correct ones.
libmirage (from Arch Linux[1]) has /usr/lib/libmirage-3.0 (and 
/usr/include/libmirage-3.0), so they do have the version in their path.


>> 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

I’d do some m4 magic. We have a well-defined versioning scheme (.90 
post-release bump) that can be automated, why not make use of it?


Cheers,


[1] <https://www.archlinux.org/packages/community/x86_64/libmirage/>

-- 

Quentin “Sardem FF7” Glidic