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