> > I strongly support requiring newer versions of Autoconf rather than using > > inferior probes or reinventing the wheel, particularly when they're > > already nearly four years old. Autoconf is improving significantly in > > ways that require one to maintain far less code in each package. If one > > absolutely must do development on a very slow-releasing platform with > > outdated software, Autoconf is trivial to install (assuming that M4 isn't > > so ancient that it can't run Autoconf). > > 2.60 requires newer than just "not ancient", apparently.
Not sure I buy that: RHEL/Centos5 is the most recent enterprise offering, so it's going to be around for a _long_ time and it is currently pegged at 1.59. I'd be the first to admit that I don't understand these things, but we probably need to make sure that people _deploying on_ enterprise operating systems are not disenfranchised. > I don't care, but it's worth noting. I guess I care personally only in that I wasted a day in an ultimately fruitless attempt to get a recent autoconf/m4 onto my Centos 5 build environment. If anyone has a proven working recipe they'd like to share (no, the fc srpms don't 'just work') I'd be grateful (like I say, I don't do a lot of this). I'll even put it into the wiki if people think that would help. /Rod _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
