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

[Emil Velikov]

On 13 July 2016 at 15:53, Jan Engelhardt <jengelh at inai.de> wrote:
>
> On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
>>
>>I think Quentin raised a good point, though. In source-based
>>distros, well, in Gentoo at least which I use almost exclusively,
>>there are no separate -devel packages.
>
> A package is, abstractly, merely a selected subset of `make install`
> artifacts. As such, you could install a -devel package (file set)
> even on a distro which has "no -devel packages", and in fact, you can
> just extend the thought to a distribution which has no concept
> "packages" at all.
>
> In other words, there is always a way to install libdb-4_5-devel, and
> uninstall it again in case one needs to make room for libdb-4_8-devel.
>
The keypoint here is that one should _not_ need to uninstall
libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa.
One must be able to just "make install" for each (major) version and
_nothing_ should be overwritten. This is what parallel installability
is all about (afaict).

Looking at the OpenSuse libdb packages [1] [2] it shows that:
 - the -devel packages will _explicitly conflict_ with one another (as
you mentioned/suggested above). Thus this approach won't fly with
source-based distros.
 - you guys install 4.5 and 4.8 headers in /usr/include/db4/ as
opposed to the upstream /usr/include/
 - each package -devel package installs conflicting headers, and
symlinks (libdb.so, libdb-${major}.so and equivalent)
 - there's a handful of source code modifications to accommodate the above.

[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/libdb-4_5/libdb-4_5.spec?expand=1
[2] https://build.opensuse.org/package/view_file/openSUSE:Factory/libdb-4_8/libdb-4_8.spec?expand=1

>
>>Would it be so bad to assume that compositor projects would not
>>bother supporting more than one (or few at most) libweston MAJOR at
>>a time?
>
> On the contrary. As a distro package recipe maintainer, you have to even
> _expect_ it will happen that a compositor requires exactly one specific
> version of libweston. (Like demonstrated, libdb already shows
> why/how solved.)
>
With the above things said libdb package(s), I would strongly suggest
against giving it/them as an example.

If you look closely at some (many?) of the GTK/Qt based applications
you'll see that they support multiple versions of the respective
toolkit. Some even support multiple version of GTK _and_ Qt at the
same time. This is exactly what's happening (being suggested) here.
Sure that means a possibility for greater permutation, more packages
to ship, maintain and test. All of those are/should be selectable at
configure time and the final decision is up-to the distros.

>>OTOH, would adding a new libweston MAJOR in an already stable and
>>released binary distribution be absolutely forbidden? It would by
>>definition not affect anything the distribution was released with,
>>unless libweston's dependencies changed, but I think the
>>dependencies might change less often than we bump MAJOR.
>
> What the distro permits is a matter of their policy. Nothing you
> should be concerned about, because what you do is just regularly
> releasing new versions of your software.
>
True. That doesn't stop him (anyone else involved) from trying to
understand the distro needs as opposed to completely ignoring them.

>>In summary, the only downside from installing all devel files
>>MAJOR-specific is that user projects need multiple pkg-config
>>checks if they want to support multiple MAJORs, right?
>>I'd vote for taking that hit and seeing if anyone complains loud
>>enough.
>
> Well, my complaint would be:
>
> I would want that compositors at the distro level to build against
> the latest libweston, assuming it succeeds. If the compositor however
> has a PKG_C_M([libweston-15]) check, I would have to update that line
> with a patch _everytime a new libweston is out_, to 16, 17, ....
Wrong, I'm afraid. You (as a distro) will chose which versions of
libweston will be shipped, and thus your software will be build
against it/them.

If that means that project A (requires too new version) and/or B
(requires too old version) may no be available. Yes, it will be
annoying if projects that you guys want to use/ship don't update
against newer libweston but that's nothing to blame on libweston. Just
communicate your points cleanly with the respective projects.

The alternative is to follow the current GTK approach and
(un)intentionally break API/ABI _between minors_. Which is a serious
no go, imho.

> This
> is why I am supporting the "do NOT version the pkgconfig filename,
> and see if anyone complains" approach. With the unversioned approach,
> if the build were not to succeed with 16/17/+, I only need to
> make/edit a patch that changes PKG_C_M([libweston]) to [libweston-15]
> _once_, and maybe revisited if and when the compositor finally
> catches up.
In general I would strongly suggest against making any long term local
source code modifications. That's not because you lack the skills
and/or knowledge (I've looked at your kernel work). Wherever possible
help projects out, by a) lobbying that they keep/add support for
version X and/or b) just send them a patch "I've added support for the
new version XX of YY". Pretty sure they'll be happy to see the latter
more ;-)

IMHO the alias suggestion sounds quite reasonable, yet afaict
pkg-config does not support it. Have you mentioned/suggested it to the
pkgconfig developers ?

TL;DR
* libdb is a classic example of _not_ parallel installable library and
the OpenSuse packaging shows the efforts needed to make it one (sort
of).
* Having multiple libweston{major} will be annoying for
distribution(s) _if_ projects using libweston do not align the
version(s) they [can] use with the one(s) provided by distros.
* The latter of which should be coordinated between the distros and
said projects.


Regards,
Emil