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 <jengelh at inai.de> 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