On 26/09/15 03:14, Greg Troxel wrote:
atomicules <base%atomicules.co.uk@localhost> writes:What I've done is, just before the bit where the GCC_REQD list gets worked down to a single, highest _GCC_REQD value, is: 1. Look for the presence of GCC_VERSIONS_ACCEPTED. 2. If it is there, check each version in the list against what is actually installed 3. Once it finds a match it sets GCC_REQD to that single value (so it picks the first found) 4. If it finds no matches then set GCC_REQD to GCC_VERSIONS_ACCEPTED * GCC_REQD and GCC_VERSIONS_ACCEPTED are trying to say more or less the same thing. So while it's probably best not to try to change it all at once, I'd like to head to a single mechanism for a package to express which versions are ok, deprecate the old ones, and convert packages to that.
Whatever the approach, it needs to work with merging requirements from multiple packages.
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.
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?
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".
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.
* Obviously the base system gcc should be used if it's ok. And if not, then there's the question of which one to pick to install, among the acceptable versions. This feels like it should perhaps be a user pref, or perhaps pkgsrc should have this hard-coded for now, perhaps picking 4.8 if that's acceptable, else the lowest acceptable version, or something like that. Or perhaps just the simplest thing and install the minimum acceptable version. All of this leads me to want to have two variables: GCC_VERSION_MIN = (lowest version that is ok for this package)
That might work if it's a list. But, actually, that's pretty much what GCC_REQD does.
Your patch could certainly introduce private variables within gcc.mk (often with a _ prefix); there's nothing magic about setting GCC_REQD and not touching existing code. This approach would have the side effect of causing most packages with GCC_REQD=4.5, for example, to be ok with a 4.8 compiler. This is actually what's documented already in mk/compiler/gcc.mk, but it seems that it doesn't do it.
I'm pretty sure that's broadly what gcc.mk is trying to do.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?
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.
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.
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?