David O'Brien wrote: > > Ports does the same thing: hand tweaks stuff instead of > > pushing the patches back to the projects that originated > > it. > > *sigh* Terry I respect your programming knowledge, but you are wrong > here. I send out a *LOT* of patches to the authors of ports I maintain > (and I know others that do so also). You might be surprised at the > number of software authors that either 1. don't care that the package is > not portable, or 2. wont answer their email.
Actually, I wouldn't. I started on a pass thorugh the ports a while back, to try and push patches back to the authors, but it's a daunting task. A lot of the ports patches (and I'm not trying to dump on anyone in particular here... I didn't start by going alphabetically ;-)) are unfortunately not push-backable. The FreeBSD specific patches break things for other platforms, or end up changing things for editorial reasons, without making the targets of those changes site options, instead of an editorial conflict with the authors of the original code (DJB is particularly bad at portraying any patch offered him as if it were an editorial comment, but other authors are not immune to the same thing, unfortunately). Needless to say, it would take a concerted effort to get rid of the FreeBSD specific patches out of the ports tree, entirely, not just the efforts of one person. A quick perusal of the /usr/ports on a 4.1 machine I have here locally ("quick" perusal?!? 8-)) shows that there are ~8000 patch files that are needed to "FreeBSD-ify" things, and that number is likely much higher with the higher number of ports, now. Maybe Open Ports, being a voice for more OSs, will have better luck. > > It's far, far better that the Makefile runs the > > autoconf/automake/configure/etc. on behalf of the contrib > > code, with no hand-tweaked files dragged in after the > > config has already been run. > > That would be nice, but the problem is autoconf/automake/configure/etc. > is WAY too sensitive to the environment in which it is running. > As one example, the C++ API supported by GCC. When configuring it looks > at the existing C++ API and matches it. Well, a while back I wanted to > change the C++ API. There is no way to do this using `configure'. > However, the way I do build the toolchain it is VERY DETERMINISTIC and I > am able to set how I want things to work in the end. This removes > dependencies on the current environment. Ugh. I was unaware that they tried to do that. It seems... uh... "brilliant"... to want to lock everyone into the 1.0 version of the API because they upgraded through all the g+ version since day 1. 8-p. Unless there are overriding concerns like that, though, I think that people doing ports should "do as you say, not as you do". 8-). GCC is, unfortunately, a very big pile of code; if anything's going to be an exception, it's that, particularly given the "release" and "buildworld" issues. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message