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

[Pekka Paalanen]

On Fri, 15 Jul 2016 18:11:57 +0200 (CEST)
Jan Engelhardt  wrote:

> On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
> >> >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. [...]
> >This is the second time I have been turned down for trying
> >to figure out what distributions would like to have from the
> >upstream.  
> 
> Well let me rephrase it then. In openSUSE, adding a package to the
> update channel (bugfix channel) is possible, as is doing so with new
> SONAME, as we support selectively rebuilding packages (already have
> to do that because of the kernel's unstability guarantee).
> 
> But I probably would not normally ship a new shiny libweston with new
> features and new APIs in the bugfix channel, so whatever new release
> may be available at freedesktop.org, it would have to wait for the
> next distro release.

Hi Jan,

I can totally agree with that. Particularly as you probabably
wouldn't include a compositor needing a new libweston on a bugfix
channel either, right? A compositor bumping its libweston major
requirement is not a bug fix by definition, so there's no
problem.

If there is a demand for bugfix releases on old major releases, I
believe we would do those, provided backporting the fix is not too
hard. But I also think users need to ask for that, since otherwise
it would be better to just concentrate on getting libweston
actually stabilized. Some way to advertise the "please do ask" would
probably be necessary from weston upstream.

In fact, this is what we already do with the stable branches of
weston and wayland - they don't see any attention if no-one asks
for it. It would be even better if we got help with them from the
people that would need them.

> So it's not really a turn-down, but I just do not have anything
> to request from upstream with regard to releases.

Ok, sorry for the confusion.


Thanks,
pq


pgp3IfynSuke_.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
>> >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. [...]
>This is the second time I have been turned down for trying
>to figure out what distributions would like to have from the
>upstream.

Well let me rephrase it then. In openSUSE, adding a package to the
update channel (bugfix channel) is possible, as is doing so with new
SONAME, as we support selectively rebuilding packages (already have
to do that because of the kernel's unstability guarantee).

But I probably would not normally ship a new shiny libweston with new
features and new APIs in the bugfix channel, so whatever new release
may be available at freedesktop.org, it would have to wait for the
next distro release.

So it's not really a turn-down, but I just do not have anything
to request from upstream with regard to releases.


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

There are so many upstreams, not all of which are welcoming changes
proposed that would benefit distros (mixture of don't know how to
implement, don't know how to maintain if implemented, don't care, or
not-interested). Then all we can do is workaround at the distro
level, especially if the package is essential. Think util-linux
which, in fully populated mode, has a cycle with systemd, which we
had to end by building it multiple times as things become
available. Not sure whatelse to have done there.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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



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?



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

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

[Jan Engelhardt]

On Thursday 2016-07-14 17:33, Emil Velikov wrote:
>
>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.
>This is what parallel installability is all about (afaict).

It is indeed what it is about.
But is it _necessary_ to have? No (IMO).
Convenient? Possibly.

Perhaps I am biased because all packages that can be built can be
built in a clean namespace where the "right" devel versions are
installed. Whether that is in a source-based distro (what a weird name,
all distros are using source somewhere) or not.

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

I will argue that they are slow moving targets (you can add wxWidgets
to the list). That's not the kind of bell that was sounded for
libweston ("be at 27 soon").

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

An AxI break is (to be) communicated by SONAME change. If they do
that for a tarball minor, well let them. What's in a release number
anyway? The Linux kernel also "changes their ABI" between minors.

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

Nope.

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

The only effort was parallel runtime installability.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: 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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Sun, 10 Jul 2016 14:34:28 +0200 (CEST)
Jan Engelhardt  wrote:

> On Sunday 2016-07-10 13:13, Quentin Glidic wrote:
> >
> > If we install only one .pc file:
> > - You cannot develop against an old version.  
> 
> I do not feel that is true. If you have Berkeley DB 4.5 in tarball
> form, you can build and `make install` it. Provided the SONAME is
> different (it is; libdb-4.5.so), it *ought* not to break the rest of
> your system which relies on libdb-4.8.so.
> 
> If you have db 4.5 in distropackage form, you can install the
> libdb-4_5.rpm library, and it won't kick out libdb-4_8, and you can
> install libdb-4_5-devel.rpm, which only kicks out libdb-4_8-devel,
> but that is a negligible fact, as distro build results show that
> no one seriously needs 4.5 and 4.8 at the same time a particular
> software component is built.
> 
> The example extends to packages other than bdb. (bdb has no .pc
> file, which is the same complexity class a one .pc file.)

Hi Jan,

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.

I haven't even looked at how Gentoo would solve the issue where you
cannot install multiple versions of library headers to allow
installing (which implies building from source) two different
programs each depending on the different version of the library and
headers.

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?

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.

I believe the burden of adding pkg-config checks will be
insignificant compared to the work needed for a compositor project
to actually work with multiple libweston MAJORs.

It's good have a seasoned packager like you (thanks for the
introduction, puts your comments in whole different perspective for
me!) to comment on these things. There are more issues I'd like
someone to sanity-check after this versioning issue gets resolved.
It would essentially boil down to checking Weston's README for the
packager notes if they make sense as a plan, and what we could do to
help packaging.

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.


Thanks,
pq


pgpRLLH1oYklk.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Monday 2016-07-11 16:44, Emil Velikov wrote:
>> Without pkgconfig supporting some new alias tag (hint, hint) to cover
>> such a case,
>No idea what such a "alias tag" is supposed to do/look like. Do you
>have examples ?

Proposed concept would be to make pkgconfig recognize
a new Alias directive:
 gtk-2.0.pc:
  Name: gtk-2.0
  Version: 2
  Alias: gtk
  @OTHER_TYPICAL_FIELDS@
 gtk-3.0.pc:
  Name: foo-3.0
  Version: 3
  Alias: gtk
Result (recap):
 A single PKG_CHECK_MODULESM([gtk], [gtk >= 2]) call may be used instead of
 the usual two or more.


>> I predict that whoever uses libfoo-LotsANumbersHere
>> limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
>> is looking real silly.
>>
>If (and that's a _huge_ if) they support more than 3-4 versions of
>libfoo, then the configure.ac will be the least ugly thing.

Heh, true: The projects which do use foo-N.pc naming move about in
slow cycles (we had dbus-1, gtk-2, libnl-3 for a long time now), and
if they change, it can be assured they threw *everything* over the
fence.

Those who have just foo.pc are kind of the Linux kernel type: it
changes a bit here and there, and every now and then, and external
components with new failed builds are comparatively easily fixable.


This should not be overdiscussed; just pick something already. {1:
Either it will work out, and all is good, or it will not work out,
gets changed and then goto 1.} :p
^ That always worked out so far.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 11 July 2016 at 17:58, Jan Engelhardt  wrote:
>
> On Monday 2016-07-11 16:44, Emil Velikov wrote:
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.
>>>
>>> I read it now, and I do not buy it - at least not for 2016 standards.
>>> According to the page, it was written in 2002, and I can confirm that
>>> the situation was much worse then it is now. I can practically refute
>>> all his points from the "Some more issues:" section, but for brevity,
>>> I spare you the details for now.
>>
>>Trying to get some understanding about your experience in the area -
>>which distribution(s) do you work with, how many packages do you
>>maintain ?
>
> openSUSE. Enlisted for 441, but my id appears in 2056 changelogs by now and I
> bear the role of global co-reviewer, i.e. some 9100 packages.
>
> And in the paid part of life: SLE, RH6,7, Ubu14/16, Univention, Collax (things
> you never heard of), Windows(*). So I am also aware about _their_
> skeletons-in-the-closet.
>
Damn, that's an impressive way of making me eat my own words ;-)

Strange part is that neither of Fedora, Debian, Gentoo + Arch plus the
Openhub $distro packages shows any results :-\ Guess I failed "at
googling"

That said, considering the discussion/confusion with others I'd
suspect you've been at our level way back. Thus some of our
assumptions/knowledge might be quite noobish. If you can
share/recommend some reading material that covers your earlier/current
concerns that'll be amazing.

Thanks
Emil

[1] https://admin.fedoraproject.org/pkgdb/packagers/
[2] https://nm.debian.org/public/people
[3] https://www.gentoo.org/inside-gentoo/developers/
[4] https://www.archlinux.org/people/developers/

>
> (*) Not a distro, but an anarchy, which is also interesting to distribute for.

Windows distribution is interesting in it's own crazy way :-P MSI,
NSIS, InstallShield, downloading MS C/.NET runtimes... heh memories.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Monday 2016-07-11 16:44, Emil Velikov wrote:
>>>http://ometer.com/parallel.html. I would strongly recommend giving it
>>>a look.
>>
>> I read it now, and I do not buy it - at least not for 2016 standards.
>> According to the page, it was written in 2002, and I can confirm that
>> the situation was much worse then it is now. I can practically refute
>> all his points from the "Some more issues:" section, but for brevity,
>> I spare you the details for now.
>
>Trying to get some understanding about your experience in the area -
>which distribution(s) do you work with, how many packages do you
>maintain ?

openSUSE. Enlisted for 441, but my id appears in 2056 changelogs by now and I
bear the role of global co-reviewer, i.e. some 9100 packages.

And in the paid part of life: SLE, RH6,7, Ubu14/16, Univention, Collax (things
you never heard of), Windows(*). So I am also aware about _their_
skeletons-in-the-closet.



(*) Not a distro, but an anarchy, which is also interesting to distribute for.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 9 July 2016 at 17:26, Pekka Paalanen  wrote:
> On Thu, 7 Jul 2016 17:45:24 +0100
> Emil Velikov  wrote:
>
>> On 7 July 2016 at 10:46, Pekka Paalanen  wrote:
>> > On Mon, 4 Jul 2016 16:25:54 +0100
>> > Emil Velikov  wrote:
>> >
>> >> On 4 July 2016 at 15:35, Quentin Glidic  
>> >> wrote:
>> >> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >> >>
>> >> >> From: Emil Velikov 
>> >> >>
>> >> >> Signed-off-by: Emil Velikov 
>> >> >> ---
>> >> >>  configure.ac  | 1 +
>> >> >>  libweston/libweston.pc.in | 2 +-
>> >> >>  2 files changed, 2 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/configure.ac b/configure.ac
>> >> >> index be40f10..46b61ae 100644
>> >> >> --- a/configure.ac
>> >> >> +++ b/configure.ac
>> >> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], 
>> >> >> [weston_minor_version])
>> >> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
>> >> >>  AC_SUBST([WESTON_VERSION], [weston_version])
>> >> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
>> >> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >> >
>> >> >
>> >> > That makes packaging a pain. Although the whole libweston (supposedly
>> >> > parallel-installable) is already a pain.
>> >> >
>> >> > When you have a project with a dep on libweston, you’ll have to dig the
>> >> > weston version because the tarball is versioned as weston.
>> >> >
>> >> > I would only do that once (and if) we split libweston and weston to
>> >> > different repositories.
>> >> >
>> >> Yes splitting libweston into separate repo makes sense. Yet I failed
>> >> to see where the actual pain is - there is a minor annoyance, and devs
>> >> and/or distro maintainers have learned to deal with a lot nastier
>> >> things through the years.
>> >>
>> >> If anything, having libweston-2 provided by (a future)
>> >> libweston-1.12.0 tarball/package would make things even more
>> >> confusing/annoying. That is unless one is planning to say "f**k it,
>> >> let's decrease the version" upon the split. With the later upsetting a
>> >> lot of people.
>> >
>> > Hi guys,
>> >
>> > my 2c again:
>> >
>> > I don't think splitting weston and libweston to separate
>> > repositories can happen any time soon, because of the test suite
>> > that is specific to weston. I do not want to duplicate the test
>> > suite, and I do not want 'make check' in libweston to be useless,
>> > so we need to keep them together for now.
>> >
>> If there were more developers, one could also move the tests into a
>> separate repo. Although that (plus libweston) would require extensive
>> audit of the private and public headers since atm, things are quite
>> fragile (one might even call them busted).
>
> More developers or not, I am not so optimistic that it would work.
>
> The tests have code intimately tied to internal APIs of both weston
> and libweston. That alone is reason enough. It may not even be
> possible to get rid of that, realistically.
>
> To be able to run libweston, we'd essentially need a copy of weston
> anyway, for initializing it.
>
Had no idea about those. I'd imagine that one could handle those with
git submodules, although that might be a bit fragile and it'll require
a ton more development effort that there is atm.

Just food for though, than a serious suggestion.

>> > I also think that we don't need separate versioning for weston and
>> > libweston. Let's just use the same for both, now that the plans are
>> > clarifying.
>> >
>> > Yes, it does mean the following:
>> >
>> > - weston version number will start to deviate from wayland, even
>> >   when both are still released at the same time
>> >
>> Don't think this is a serious problem, I've even recall people being
>> confused why they are still in sync.
>
> Heh, cool.
>
>> > - weston version number will be the same as libweston it uses
>> >
>> > - MAJOR will start running like hell, we'll probably get to weston
>> >   27.0.0 before it slows down, or whatever
>> >
>> > But, that's all fine with me, considering the confusion any other
>> > scheme would raise.
>> >
>> > I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
>> > of weston, installing libweston-1.so, and then we'd just bump to
>> > weston 2.0.0 on the next final release.
>> >
>> > How's that?
>> >
>> This sounds like a good plan to me, fwiw.
>
> Alright.
>
>> > Hmm... but again, if we use MAJOR like that, then during the
>> > development of 2.0.0 we would be still installing libweston-1.so
>> > because our version in git master is 1.12.90 until the first
>> > pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
>> > How to solve that? Or is it not a problem?
>> >
>> > The thing is, libweston 1.12.90 will be completely incompatible
>> > with libweston 1.12.0.
>> >
>> > Should .9x be a special case somehow, installed as
>> > libweston-1-90.so or such?
>> >
>> As mentioned elsewhere - one should not rely on development version of
>> proje

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

[Emil Velikov]

On 10 July 2016 at 13:23, Jan Engelhardt  wrote:
>
> On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>>> 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.
>
> Without pkgconfig supporting some new alias tag (hint, hint) to cover
> such a case,
No idea what such a "alias tag" is supposed to do/look like. Do you
have examples ?

> I predict that whoever uses libfoo-LotsANumbersHere
> limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
> is looking real silly.
>
If (and that's a _huge_ if) they support more than 3-4 versions of
libfoo, then the configure.ac will be the least ugly thing.

>>> 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 (main?) problem [...] is that 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.
>
> I read it now, and I do not buy it - at least not for 2016 standards.
> According to the page, it was written in 2002, and I can confirm that
> the situation was much worse then it is now. I can practically refute
> all his points from the "Some more issues:" section, but for brevity,
> I spare you the details for now.
>
It's fine to disagree. From what I've seen working with package
maintainers and other my own experience, most people (still) share the
sentiments mentioned in the page.

Trying to get some understanding about your experience in the area -
which distribution(s) do you work with, how many packages do you
maintain ?


>
>>> 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 ;-)
>
> Feels wrong to pollute configure.ac with code that tries to be
> "smart" but is foremost disproportional in size to the problem.
One could handle this in multiple ways - in configure, separate script
and/or hooks.

> (And
> you wonder why people hate $build_system_du_jour.) Would a commit
> hook not be better to run a check that SONUM is in good shape w.r.t.
> VERSION?
>
As _everything_ in life, people hate X because they don't understand
it. Once your project gets complex enough and your build system is
comprehensive enough to handle it things always looks scary/nasty.

But all of that is an orthogonal, imho.

-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Sunday 2016-07-10 13:13, Quentin Glidic wrote:
>
> If we install only one .pc file:
> - You cannot develop against an old version.

I do not feel that is true. If you have Berkeley DB 4.5 in tarball
form, you can build and `make install` it. Provided the SONAME is
different (it is; libdb-4.5.so), it *ought* not to break the rest of
your system which relies on libdb-4.8.so.

If you have db 4.5 in distropackage form, you can install the
libdb-4_5.rpm library, and it won't kick out libdb-4_8, and you can
install libdb-4_5-devel.rpm, which only kicks out libdb-4_8-devel,
but that is a negligible fact, as distro build results show that
no one seriously needs 4.5 and 4.8 at the same time a particular
software component is built.

The example extends to packages other than bdb. (bdb has no .pc
file, which is the same complexity class a one .pc file.)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>> 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.

Without pkgconfig supporting some new alias tag (hint, hint) to cover
such a case, I predict that whoever uses libfoo-LotsANumbersHere
limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
is looking real silly.

>> 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 (main?) problem [...] is that 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.

I read it now, and I do not buy it - at least not for 2016 standards.
According to the page, it was written in 2002, and I can confirm that
the situation was much worse then it is now. I can practically refute
all his points from the "Some more issues:" section, but for brevity,
I spare you the details for now.


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

Feels wrong to pollute configure.ac with code that tries to be
"smart" but is foremost disproportional in size to the problem. (And
you wonder why people hate $build_system_du_jour.) Would a commit
hook not be better to run a check that SONUM is in good shape w.r.t.
VERSION?

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: 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] 

--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: 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  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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

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

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

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Thu, 7 Jul 2016 17:45:24 +0100
Emil Velikov  wrote:

> On 7 July 2016 at 10:46, Pekka Paalanen  wrote:
> > On Mon, 4 Jul 2016 16:25:54 +0100
> > Emil Velikov  wrote:
> >  
> >> On 4 July 2016 at 15:35, Quentin Glidic  
> >> wrote:  
> >> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >> >>
> >> >> From: Emil Velikov 
> >> >>
> >> >> Signed-off-by: Emil Velikov 
> >> >> ---
> >> >>  configure.ac  | 1 +
> >> >>  libweston/libweston.pc.in | 2 +-
> >> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/configure.ac b/configure.ac
> >> >> index be40f10..46b61ae 100644
> >> >> --- a/configure.ac
> >> >> +++ b/configure.ac
> >> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], 
> >> >> [weston_minor_version])
> >> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
> >> >>  AC_SUBST([WESTON_VERSION], [weston_version])
> >> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
> >> >> +AC_SUBST([LIBWESTON_VERSION],
> >> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
> >> >>   
> >> >
> >> >
> >> > That makes packaging a pain. Although the whole libweston (supposedly
> >> > parallel-installable) is already a pain.
> >> >
> >> > When you have a project with a dep on libweston, you’ll have to dig the
> >> > weston version because the tarball is versioned as weston.
> >> >
> >> > I would only do that once (and if) we split libweston and weston to
> >> > different repositories.
> >> >  
> >> Yes splitting libweston into separate repo makes sense. Yet I failed
> >> to see where the actual pain is - there is a minor annoyance, and devs
> >> and/or distro maintainers have learned to deal with a lot nastier
> >> things through the years.
> >>
> >> If anything, having libweston-2 provided by (a future)
> >> libweston-1.12.0 tarball/package would make things even more
> >> confusing/annoying. That is unless one is planning to say "f**k it,
> >> let's decrease the version" upon the split. With the later upsetting a
> >> lot of people.  
> >
> > Hi guys,
> >
> > my 2c again:
> >
> > I don't think splitting weston and libweston to separate
> > repositories can happen any time soon, because of the test suite
> > that is specific to weston. I do not want to duplicate the test
> > suite, and I do not want 'make check' in libweston to be useless,
> > so we need to keep them together for now.
> >  
> If there were more developers, one could also move the tests into a
> separate repo. Although that (plus libweston) would require extensive
> audit of the private and public headers since atm, things are quite
> fragile (one might even call them busted).

More developers or not, I am not so optimistic that it would work.

The tests have code intimately tied to internal APIs of both weston
and libweston. That alone is reason enough. It may not even be
possible to get rid of that, realistically.

To be able to run libweston, we'd essentially need a copy of weston
anyway, for initializing it.

> > I also think that we don't need separate versioning for weston and
> > libweston. Let's just use the same for both, now that the plans are
> > clarifying.
> >
> > Yes, it does mean the following:
> >
> > - weston version number will start to deviate from wayland, even
> >   when both are still released at the same time
> >  
> Don't think this is a serious problem, I've even recall people being
> confused why they are still in sync.

Heh, cool.

> > - weston version number will be the same as libweston it uses
> >
> > - MAJOR will start running like hell, we'll probably get to weston
> >   27.0.0 before it slows down, or whatever
> >
> > But, that's all fine with me, considering the confusion any other
> > scheme would raise.
> >
> > I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
> > of weston, installing libweston-1.so, and then we'd just bump to
> > weston 2.0.0 on the next final release.
> >
> > How's that?
> >  
> This sounds like a good plan to me, fwiw.

Alright.

> > Hmm... but again, if we use MAJOR like that, then during the
> > development of 2.0.0 we would be still installing libweston-1.so
> > because our version in git master is 1.12.90 until the first
> > pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
> > How to solve that? Or is it not a problem?
> >
> > The thing is, libweston 1.12.90 will be completely incompatible
> > with libweston 1.12.0.
> >
> > Should .9x be a special case somehow, installed as
> > libweston-1-90.so or such?
> >  
> As mentioned elsewhere - one should not rely on development version of
> project foo having stable interface(s). That said, making sure that
> things aren't too crazy for people that do want to test them is a must
> imho.
> Nobody (?) wants to deter their testers away.

This issue is being discussed in my reply to Jan, so I'd prefer to
continue in that part of the thread.

> > This is starting to sound very much like what I read about GTK
> > trying a new versioning

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

[Pekka Paalanen]

On Sat, 9 Jul 2016 05:19:26 +0200 (CEST)
Jan Engelhardt  wrote:

> On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
> >> >> +AC_SUBST([LIBWESTON_VERSION],
> >> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
> >> >> 
> >> >
> >> > That makes packaging a pain. Although the whole libweston (supposedly
> >> > parallel-installable) is already a pain.  
> 
> First, what kind of parallel installability is sought?
> 
> * just runtime
> * parallel development environment (like what e.g. libabw,
>   librevenge.. do)

Hi,

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?

> >- MAJOR will start running like hell, we'll probably get to weston
> >  27.0.0 before it slows down, or whatever  
> 
> - do you care about release numbering? (Projects with equally high
>   numbers don't anymore; like Chrome, Firefox, systemd)

I don't mind (anymore).

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

> - I imagine that no one cares about the SONAME either, so you could
>   try banishing the SO version into the basename and getting away with
>   it. Might cause $confusion.
>   (libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

I'd like to avoid such confusion if possible, and use simply (the
to be when released) MAJOR  in the SONAME.

> 
> >Hmm... but again, if we use MAJOR like that, then during the
> >development of 2.0.0 we would be still installing libweston-1.so
> >because our version in git master is 1.12.90 until the first
> >pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
> >How to solve that? Or is it not a problem?  
> 
> Some projects make the bump at the start of the development cycle,
> some do it just before the tarball release, and some do it together
> with the first incompatible change (i.e. midway).
> 
> To be really foolproof, every _commit_ that changes things in an
> incompatible way would need a bump, but that is too much hassle for
> most, so they just do it between tarball releases in one of the three
> just-mentioned ways.

We have been bumping the project version to 1.y.90 right after the
release of 1.y.0, at the start of the development cycle. This way
unreleased projects can depend on our unreleased project.

> >The thing is, libweston 1.12.90 will be completely incompatible
> >with libweston 1.12.0.
> >
> >Should .9x be a special case somehow, installed as
> >libweston-1-90.so or such?  
> 
> Since 1.12.90 is probably not incompatible to 1.13.0,
> they both would install whatever 1.13.0 would have used.

Indeed, yes.

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.


Thanks,
pq


pgpJzgLESDe_h.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jan Engelhardt]

On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >>   
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a pain.

First, what kind of parallel installability is sought?

* just runtime
* parallel development environment (like what e.g. libabw,
  librevenge.. do)

Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.


>- MAJOR will start running like hell, we'll probably get to weston
>  27.0.0 before it slows down, or whatever

- do you care about release numbering? (Projects with equally high
  numbers don't anymore; like Chrome, Firefox, systemd)
- 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
- I imagine that no one cares about the SONAME either, so you could
  try banishing the SO version into the basename and getting away with
  it. Might cause $confusion.
  (libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

>Hmm... but again, if we use MAJOR like that, then during the
>development of 2.0.0 we would be still installing libweston-1.so
>because our version in git master is 1.12.90 until the first
>pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
>How to solve that? Or is it not a problem?

Some projects make the bump at the start of the development cycle,
some do it just before the tarball release, and some do it together
with the first incompatible change (i.e. midway).

To be really foolproof, every _commit_ that changes things in an
incompatible way would need a bump, but that is too much hassle for
most, so they just do it between tarball releases in one of the three
just-mentioned ways.

>The thing is, libweston 1.12.90 will be completely incompatible
>with libweston 1.12.0.
>
>Should .9x be a special case somehow, installed as
>libweston-1-90.so or such?

Since 1.12.90 is probably not incompatible to 1.13.0,
they both would install whatever 1.13.0 would have used.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 7 July 2016 at 10:46, Pekka Paalanen  wrote:
> On Mon, 4 Jul 2016 16:25:54 +0100
> Emil Velikov  wrote:
>
>> On 4 July 2016 at 15:35, Quentin Glidic  
>> wrote:
>> > On 04/07/2016 16:23, Emil Velikov wrote:
>> >>
>> >> From: Emil Velikov 
>> >>
>> >> Signed-off-by: Emil Velikov 
>> >> ---
>> >>  configure.ac  | 1 +
>> >>  libweston/libweston.pc.in | 2 +-
>> >>  2 files changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/configure.ac b/configure.ac
>> >> index be40f10..46b61ae 100644
>> >> --- a/configure.ac
>> >> +++ b/configure.ac
>> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
>> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
>> >>  AC_SUBST([WESTON_VERSION], [weston_version])
>> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a pain.
>> >
>> > When you have a project with a dep on libweston, you’ll have to dig the
>> > weston version because the tarball is versioned as weston.
>> >
>> > I would only do that once (and if) we split libweston and weston to
>> > different repositories.
>> >
>> Yes splitting libweston into separate repo makes sense. Yet I failed
>> to see where the actual pain is - there is a minor annoyance, and devs
>> and/or distro maintainers have learned to deal with a lot nastier
>> things through the years.
>>
>> If anything, having libweston-2 provided by (a future)
>> libweston-1.12.0 tarball/package would make things even more
>> confusing/annoying. That is unless one is planning to say "f**k it,
>> let's decrease the version" upon the split. With the later upsetting a
>> lot of people.
>
> Hi guys,
>
> my 2c again:
>
> I don't think splitting weston and libweston to separate
> repositories can happen any time soon, because of the test suite
> that is specific to weston. I do not want to duplicate the test
> suite, and I do not want 'make check' in libweston to be useless,
> so we need to keep them together for now.
>
If there were more developers, one could also move the tests into a
separate repo. Although that (plus libweston) would require extensive
audit of the private and public headers since atm, things are quite
fragile (one might even call them busted).

> I also think that we don't need separate versioning for weston and
> libweston. Let's just use the same for both, now that the plans are
> clarifying.
>
> Yes, it does mean the following:
>
> - weston version number will start to deviate from wayland, even
>   when both are still released at the same time
>
Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

> - weston version number will be the same as libweston it uses
>
> - MAJOR will start running like hell, we'll probably get to weston
>   27.0.0 before it slows down, or whatever
>
> But, that's all fine with me, considering the confusion any other
> scheme would raise.
>
> I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
> of weston, installing libweston-1.so, and then we'd just bump to
> weston 2.0.0 on the next final release.
>
> How's that?
>
This sounds like a good plan to me, fwiw.

> Hmm... but again, if we use MAJOR like that, then during the
> development of 2.0.0 we would be still installing libweston-1.so
> because our version in git master is 1.12.90 until the first
> pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
> How to solve that? Or is it not a problem?
>
> The thing is, libweston 1.12.90 will be completely incompatible
> with libweston 1.12.0.
>
> Should .9x be a special case somehow, installed as
> libweston-1-90.so or such?
>
As mentioned elsewhere - one should not rely on development version of
project foo having stable interface(s). That said, making sure that
things aren't too crazy for people that do want to test them is a must
imho.
Nobody (?) wants to deter their testers away.

> This is starting to sound very much like what I read about GTK
> trying a new versioning scheme...
>
That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?

"Versionning - there's always more to it than one expects" ;-)

Thanks
Emil

[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Pekka Paalanen]

On Mon, 4 Jul 2016 16:25:54 +0100
Emil Velikov  wrote:

> On 4 July 2016 at 15:35, Quentin Glidic  
> wrote:
> > On 04/07/2016 16:23, Emil Velikov wrote:  
> >>
> >> From: Emil Velikov 
> >>
> >> Signed-off-by: Emil Velikov 
> >> ---
> >>  configure.ac  | 1 +
> >>  libweston/libweston.pc.in | 2 +-
> >>  2 files changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index be40f10..46b61ae 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
> >>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
> >>  AC_SUBST([WESTON_VERSION], [weston_version])
> >>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
> >> +AC_SUBST([LIBWESTON_VERSION],
> >> [libweston_major_version.libweston_minor_version.libweston_patch_version]) 
> >>  
> >
> >
> > That makes packaging a pain. Although the whole libweston (supposedly
> > parallel-installable) is already a pain.
> >
> > When you have a project with a dep on libweston, you’ll have to dig the
> > weston version because the tarball is versioned as weston.
> >
> > I would only do that once (and if) we split libweston and weston to
> > different repositories.
> >  
> Yes splitting libweston into separate repo makes sense. Yet I failed
> to see where the actual pain is - there is a minor annoyance, and devs
> and/or distro maintainers have learned to deal with a lot nastier
> things through the years.
> 
> If anything, having libweston-2 provided by (a future)
> libweston-1.12.0 tarball/package would make things even more
> confusing/annoying. That is unless one is planning to say "f**k it,
> let's decrease the version" upon the split. With the later upsetting a
> lot of people.

Hi guys,

my 2c again:

I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep them together for now.

I also think that we don't need separate versioning for weston and
libweston. Let's just use the same for both, now that the plans are
clarifying.

Yes, it does mean the following:

- weston version number will start to deviate from wayland, even
  when both are still released at the same time

- weston version number will be the same as libweston it uses

- MAJOR will start running like hell, we'll probably get to weston
  27.0.0 before it slows down, or whatever

But, that's all fine with me, considering the confusion any other
scheme would raise.

I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
of weston, installing libweston-1.so, and then we'd just bump to
weston 2.0.0 on the next final release.

How's that?

Hmm... but again, if we use MAJOR like that, then during the
development of 2.0.0 we would be still installing libweston-1.so
because our version in git master is 1.12.90 until the first
pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
How to solve that? Or is it not a problem?

The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.

Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

This is starting to sound very much like what I read about GTK
trying a new versioning scheme...


Thanks,
pq


pgpBTiQFbuFOb.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Emil Velikov]

On 4 July 2016 at 15:35, Quentin Glidic  wrote:
> On 04/07/2016 16:23, Emil Velikov wrote:
>>
>> From: Emil Velikov 
>>
>> Signed-off-by: Emil Velikov 
>> ---
>>  configure.ac  | 1 +
>>  libweston/libweston.pc.in | 2 +-
>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index be40f10..46b61ae 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
>>  AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
>>  AC_SUBST([WESTON_VERSION], [weston_version])
>>  AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
>> +AC_SUBST([LIBWESTON_VERSION],
>> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>
>
> That makes packaging a pain. Although the whole libweston (supposedly
> parallel-installable) is already a pain.
>
> When you have a project with a dep on libweston, you’ll have to dig the
> weston version because the tarball is versioned as weston.
>
> I would only do that once (and if) we split libweston and weston to
> different repositories.
>
Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.

If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

-Emil
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Quentin Glidic]

On 04/07/2016 16:23, Emil Velikov wrote:

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 configure.ac  | 1 +
 libweston/libweston.pc.in | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
 AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
 AC_SUBST([WESTON_VERSION], [weston_version])
 AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION], 
[libweston_major_version.libweston_minor_version.libweston_patch_version])


That makes packaging a pain. Although the whole libweston (supposedly 
parallel-installable) is already a pain.


When you have a project with a dep on libweston, you’ll have to dig the 
weston version because the tarball is versioned as weston.


I would only do that once (and if) we split libweston and weston to 
different repositories.




 m4_define([lt_current], [libweston_minor_version])
 m4_define([lt_revision], [libweston_patch_version])
 m4_define([lt_age], [libweston_minor_version])
diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index bb95af9..41ea8d7 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@

 Name: libweston API
 Description: Header files for libweston compositors development
-Version: @WESTON_VERSION@
+Version: @LIBWESTON_VERSION@
 Requires.private: wayland-server pixman-1 xkbcommon
 Cflags: -I${includedir}
 Libs: -L${libdir} -lweston-@LIBWESTON_ABI_VERSION@




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 6/6] libweston: do not use weston version in libweston.pc

[Emil Velikov]

From: Emil Velikov 

Signed-off-by: Emil Velikov 
---
 configure.ac  | 1 +
 libweston/libweston.pc.in | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
 AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
 AC_SUBST([WESTON_VERSION], [weston_version])
 AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION], 
[libweston_major_version.libweston_minor_version.libweston_patch_version])
 m4_define([lt_current], [libweston_minor_version])
 m4_define([lt_revision], [libweston_patch_version])
 m4_define([lt_age], [libweston_minor_version])
diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index bb95af9..41ea8d7 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@
 
 Name: libweston API
 Description: Header files for libweston compositors development
-Version: @WESTON_VERSION@
+Version: @LIBWESTON_VERSION@
 Requires.private: wayland-server pixman-1 xkbcommon
 Cflags: -I${includedir}
 Libs: -L${libdir} -lweston-@LIBWESTON_ABI_VERSION@
-- 
2.8.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel