Date: Mon, 03 Jun 2002 16:17:14 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kris Kennaway <kris@obsecurity.org> Cc: current@FreeBSD.org Subject: Re: State of the ports collection Message-ID: <3CFBF8FA.4D526DB6@mindspring.com> References: <20020603134224.A29126@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > * (lots of ports) The new C++ compiler deprecated a lot of headers by > moving them to a different directory: this breaks a heck of a lot of > ports). IMO we should be searching this directory by default. Then it's not really deprecated (IMO, they were deprecated by the "I don't use them, you shouldn't use them" approach, rather than thought through carefully). How long does it take to build world + all ports, vs. just "world", if what you are doing is building everything, not caring about correcting ports dependencies? E.g. not serializing through the ports build farm process? Is it reasonable to maybe set aside a machine that you can use to build everything together, and then automatically sort out things like header changes? Headers seem pretty fluid right now... 8-(. > * (lots of ports) The new C/C++ compilers caused the usual round of > breakage of marginal code. When I went to using my new chisel instead of my old chisel, for making square cuts, a lot of woodworking processes broke... but I blame the wood, not the new chisel... > * (>27 ports) The <machine/soundcard.h> header was moved, breaking Glue header; "#warning" about deprecation (tiny, obvious fix). > * (>35 ports) Something caused sys_nerr to change prototypes. It looks > like this might be because the definition of __const from > <sys/ctypes.h> has changed, but I can't see why. See for example > > http://bento.freebsd.org/errorlogs/5-latest/bogosort-0.3.3.log I can't see why, either. Because you forgot to include line 126 of "error.c" and line 238 of "stdio.h". > * (>20 ports) Recent changes to bsd.*.mk have broken a lot of ports, > namely those using the ${INSTALL} macros, but also other ports which > used their features. 8-(. > * (>19 ports) There are still a lot of ports broken by old stdio > changes that redefine stdin/out/err. For example: > > http://bento.freebsd.org/errorlogs/5-latest/bwbasic-2.20p2.log I didn't like the stdio changes when they happened. Now I like them less. > For the full list of breakage, see > > http://bento.freebsd.org/errorlogs/5-latest/ > > I think src committers need to start taking more responsibility for > the effects of changes they make to the base system, and fixing ports > which are broken by changes they make. It seems like ports committers > are not able to keep up with the rate at which ports are being broken > by -current changes: if this keeps going we'll end up shipping a > 5.0-RELEASE which has only 3 working packages. For about 2/3rds of the problems, it's easy to agree that this is a problem with the OS gratuitously changing out from under the ports. But for about 1/3 of them, it's a case of the OS changing out from under the ports without an adequate "heads up!". Saying that you are changing something in some esoteric place really assumes that everyone knows the fault tree that depends from every esoteric place in the system you could ever change. A "compile all ports on a significant header change" box would be a pretty ideal solution, if it could be done, and if doing it did not take forever. Rather than making it a rule that people have to use it, though, we could just bitch at them mercilessly when things break. 8-). The "glue header missing" breakage is pretty obviously a case of "a bad idea gone worse in realization". But it's really not reasonable to expect that everyone who's going to be making a change know what ports it could impack, without having all the ports source code laid out in front of them so that they could grep it, or at least attempt a compile. Headers should remain constant, where possible, but... when not possible... it would be nice to at least have a common way to warn about them. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CFBF8FA.4D526DB6>