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

[Pekka Paalanen]

On Wed, 13 Jul 2016 16:53:27 +0200 (CEST)
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.

Hi Jan,

that sounds to me as "you can do whatever you want, just write the
code." True, and unhelpful. I could waste gigabytes of disk and
days of CPU time just to set up a "clean build environment" for
installing a single program, but I won't and Gentoo doesn't.
(Setting up each dependency implies building that from source.)

Gentoo does not have a "clean build environment" at all. Everything
gets built against what is actually installed in the system. If a
program to be installed needs a dependency only for building, that
dependency will be first installed *in the running system*, not in
some staged "clean namespace".

You can call that a defect in Gentoo, but that's how it rolls.

I sure would wish libweston to be packaged in Gentoo in a way that
you can also install several different compositors requiring
different libweston majors at the same time. But if we don't
implement that parallel-installability already in upstream, I
believe no-one will bother patching it for Gentoo. And if they
patch it, why shouldn't we take those patches upstream then?

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

Umm, I suppose we agree here?

I just meant that user projects would not have too many pkg-config
checks since they wouldn't support too many libweston majors at a
time. I expect users to abandon old libweston major when migrating
to a new one because maintaining the alternate paths is too much
work and confusion.

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

That's true about policy, yes, but I'm getting a strange vibe here.
You too seem to advocate ignoring distributions rather than taking
them into account.

<off-topic>

This is the second time I have been turned down for trying
to figure out what distributions would like to have from the
upstream. It's as if packagers were actually happy dealing with
projects making their distribution work hard and having to
maintain intrusive, sketchy patches just to get the thing built and
installed in the right places.

The earlier time was when I though that avoiding circular
dependencies between projects/packages was a good thing, and I got
told "why would you even care about that, distributions can deal
with it". (Not by anyone on this thread.)

Yes, you can deal with anything. Wouldn't you rather avoid pain
though?

</off-topic>

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

The assumption is the wrong way. You must assume that if major
changes the build will fail or at least running will fail.

> has a PKG_C_M([libweston-15]) check, I would have to update that line

I would never expect a packager to change the check. That is why we
want to make libweston parallel-installable with different majors,
and we want to do that upstream, so that it would be easier for all
distributions to have it parallel-installable rather than not.

> with a patch _everytime a new libweston is out_, to 16, 17, .... This

Having to update that explicitly is the whole point. We bumped the
major, you have to re-review all your code to see if it still
works. Changing the number is insignificant compared to your other
worries.

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

User projects cannot predict how libweston will change in a future
release, therefore they should *by default* depend on a specific
major and reject all other majors, less or greater.

I must be misunderstanding a whole lot of things, because to me it
sounds like you want us to maximize the burden on packagers. I
suppose other packagers might agree, but it will also hit
developers and anyone wanting to build compositors (not libweston)
from source manually, and the latter people are those we *really*
need for getting libweston forward.

In summary, yes, I suppose we should ignore distributions and do
what we think might be best for the people we target: developers
foremost, and end-users the second. Packagers can always patch
things any way they want.

I also think that what 'make install' produces should be the
upstream recommended file/directory layout for all installations.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160715/c7b63acf/attachment.sig>