atomicules <base%atomicules.co.uk@localhost> writes: > I'm still happy to carry on having a go at implementing whatever is > needed. But I'm not sure what the consensus is on the approach > required? > > Do we still want a list of incompatible versions? And a > PKGSRC_GCC_MIN? Not sure about consensus, but: I would like the version variable for each package to be a single min version, and eventually also support antoher variable with incompatible versions. However, it's not clear that greater-and-incompat exists all that often in reality, so defining that in the docs with a not-implemented-yet note seems fine. I have mixed opinions about picking an installed acceptable vs deterministic choosing. I tend to go with deterministic and let people give a min if they want, since deterministic is good. Perhaps we should set a min with ?=, so that the normal case is not problematic. PKGSRC_GCC_MIN also seems like a good idea. I would use it to say "any time we are building with gcc, use at least PKGSRC_GCC_MIN". Another approach is "any time we are building with gcc and base isn't good enough, use at least PKGSRC_GCC_MIN". and really if we end up with PKGSRC_GCC_MIN and PKGSRC_GCC_FORCE that would be fine. I don't think we really know why we need those exactly and thus it's hard to figure out. The really tricky part is the notion of inheriting versions from other packages that a package depends on. I see the point, but it opens up many cans of worms, so I would be inclined to skip this for now, and to have a different mechanism (really, different variable to set in bl3) when it is time to do that part. In general, I think if we can solve part of the problem and leave the rest for later without incurring significantly more pain because of the split, doing half is a win. I definitely would like to see diffs to mk/compiler/gcc.mk fixing up the specs for variables and documenting the new behavior, even before code. Writing really clear text will help clarify the difficult details.
Description: PGP signature