On 13 July 2016 at 15:53, Jan Engelhardt <jeng...@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. > 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's not because you lack the skills and/or knowledge (I've looked at your kernel work). Wherever possible help projects out, by a) lobbying that they keep/add support for version X and/or b) just send them a patch "I've added support for the new version XX of YY". Pretty sure they'll be happy to see the latter more ;-) IMHO the alias suggestion sounds quite reasonable, yet afaict pkg-config does not support it. Have you mentioned/suggested it to the pkgconfig developers ? 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). * Having multiple libweston{major} will be annoying for distribution(s) _if_ projects using libweston do not align the version(s) they [can] use with the one(s) provided by distros. * The latter of which should be coordinated between the distros and said projects. Regards, Emil _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel