David Sainty <david.sainty%gmail.com@localhost> writes: > Whatever the approach, it needs to work with merging requirements from > multiple packages. Or at least be no more un-extendable than what we have now. > E.g. If you are installing X, which likes GCC 4.5 and up, but it > buildlinks in Y which adds a requirement for GCC 4.8 and up, then the > final selection has to be GCC 4.8 and up. The real question is to what extent the compilers are ABI compatible, or not. It seems generally they are. But then there's using e.g gcc49-libs. I am curious if you think the no-mixing rule is only about packages that use gccXY-libs, or if it's more general. > Looking for a match in GCC_VERSIONS_ACCEPTED doesn't seem to cope with > that? If it had a list that said "4.5 4.8", it would happily > (erroneously) choose 4.5, I take it? We'd have to somehow find a version which matches the intersection of each packages allowed versions, and force it. That feels too complicated. > Note that prior art in Pkgsrc for *_ACCEPTED variables is > (universally?) different to GCC. For Apache, PHP, Emacs, Python the > decision for which package is to be used has already been made. The > package is indicating whether it is compatible with that decision. The > result is either "Ok", or "Fail". That's a good point. But packages built with different gcc can often interwork, which is not really true of python. > With GCC the package is participating in choosing which GCC to use - > the decision hasn't been made yet, and will be made based on the > information from multiple packages (current + buildlinked packages). > The result will normally never be "Fail", it'll be an agreed best > option out of "native", "gcc45", "gcc48", etc... > > That could suggest that *_ACCEPTED is the wrong pattern to use for GCC. Do you mean wrong semantics, or a confusing name, or ? > I think what it doesn't do is take note that if the native compiler is > 4.4, the package needs 4.5, and gcc48 happens to be installed then it > could use gcc48 - it'll install gcc45 instead. Is that what you have > in mind? Yes, that's more or less what I meant. > On the other hand, having it use gcc48 automatically if it's installed > is not great for repeatability of builds. There's an argument to be > made there that it shouldn't use gcc48 just because it happens to be > there, because you'll start to experience different package results on > the same machine with the same configuration depending on package > build order. That's also a good point. > What would be nice is being able to explicitly set something like > PKGSRC_GCC_MIN in /etc/mk.conf to 4.8, to tell Pkgsrc that if it's > going to install a GCC package (I.e. native compiler isn't enough) > then jump straight up to 4.8. That almost feels like picking gcc/clang at bootstrap time, and could lead to using gcc48 to build everything because some packages need 4.8. It seems nonobvious if that's a good plan. > In fact, if a user-mk.conf-settable PKGSRC_GCC_MIN was supported, and > GCC_REQD was left as it is, I think all my personal use cases would be > satisfied :) Is there a compelling use case for something more > complicated? The problem I have with GCC_REQD is that it tends to be set to one value, and is documented to take a list, and there isn't an easy way to express that anything >= X is ok, except for a few values, so it will often be out of date or not really expressive enough. One could argue that almost no packages need to exclude versions above the min, but it often seems that too old lacks features and too new throws errors. I'm not really suggesting that the way GCC_REQD is intended to work be totally changed - just that we have a way to express min and incompat vs a list of ok to have a representation that is more robust against changes. Your notion of the user giving a version to jump to beyond the system version sounds sensible, to avoid the mixing issue (both from failures and the pain of building many versions).
Attachment:
pgpUf2rqpJyRI.pgp
Description: PGP signature