On Wed, 13 Jul 2016 16:53:27 +0200 (CEST) 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. 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. <off-topic> 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? </off-topic> > >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 insignificant compared to your other worries. > 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. User projects cannot predict how libweston will change in a future release, therefore they should *by default* depend on a specific major and reject all other majors, less or greater. I must be misunderstanding a whole lot of things, because to me it sounds like you want us to maximize the burden on packagers. I suppose other packagers might agree, but it will also hit developers and anyone wanting to build compositors (not libweston) from source manually, and the latter people are those we *really* need for getting libweston forward. In summary, yes, I suppose we should ignore distributions and do what we think might be best for the people we target: developers foremost, and end-users the second. Packagers can always patch things any way they want. I also think that what 'make install' produces should be the upstream recommended file/directory layout for all installations. Thanks, pq
pgpIRpfb2da8O.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
