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

[Emil Velikov]

On 4 July 2016 at 15:35, Quentin Glidic <sardemff7+wayland at sardemff7.net> wrote:
> On 04/07/2016 16:23, Emil Velikov wrote:
>>
>> From: Emil Velikov <emil.velikov at collabora.com>
>>
>> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>> ---
>>  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