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

[Jan Engelhardt]

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.


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

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

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