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,

Maybe Open Ports, being a voice for more OSs, will have better

> > 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

Reply via email to