Date: Tue, 15 May 2001 00:20:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: dannyman <dannyman@toldme.com> Cc: Kris Kennaway <kris@obsecurity.org>, Neil Blakey-Milner <nbm@mithrandr.moria.org>, Brad Knowles <brad.knowles@skynet.be>, freebsd-ports@FreeBSD.ORG, Terry Lambert <tlambert@primenet.com>, Joseph Mallett <jmallett@newgold.net> Subject: Re: How to tell ports to work on FreeBSD 3.x Message-ID: <3B00D8D4.CBF6050F@mindspring.com> References: <20010509140838.C17000@dell.dannyland.org> <200105100026.RAA04754@usr06.primenet.com> <20010509180154.E17000@dell.dannyland.org> <p05100308b7203779c364@[194.78.241.123]> <20010510143702.A84503@rapier.smartspace.co.za> <20010513140646.B63072@xor.obsecurity.org> <20010513182210.G58926@dell.dannyland.org>
next in thread | previous in thread | raw e-mail | index | archive | help
dannyman wrote: > Bear in mind that many uptight people frown on this behaviour, > and that your ancient Operating System is soooo 2000, so if > you find that the ports system has gone and destroyed your > machine, it is because you've not heeded our warnings and > pretended you knew what you were doing. We TOLD you to just > run your box through a major OS upgrade! I guess this was backhanded to me? I'm not that uptight... 8-). The big problem is that the /usr/share/mk files and the /usr/ports/Mk files often need to match each other fairly closely, since the ports targets frequently use targets in included bsd.*.mk files to do their dirty work. There are also rather large issues with things like the C++ compiler requirements for KDE, etc.. Unfortunately, you can't just upgrade the compiler with a port, even though one exists, because building requires use of DESTDIR, and that breaks threaded exception handling and RTTI in a ports-installed newer version of the compiler, because the -I in CXXFLAGS gets forced back to the system defaults in bsd.prog.mk and bsd.lib.mk. There are also "ports" that are actually binaries, such as the Netscape ports, which depend on specific versions of libraries to be able to do their thing -- libraries which don't exist. Further, there's a lot of _crud_ in the base system these days, which brings in a bunch of things, like RSA in libcrypto, libssl, etc., which weren't formerly there; any ports that link with these libraries are going to assume that they are there, if the ports are for a newer system; this class of assumption alone will break around 20% of all the ports. And that's ignoring the include file changes, the cred structure (xucred/kcred) stuff, and all similar things. I can't say that I'm personally happy at all about the dropping of pre-4.x support for ports; on the other hand, I understand it because of issues like those above, and even worse ones that I didn't bother to mention. So there are a lot of dragons lurking in there, and trying to pretend it's a non-problem is really hard. If you were to build all of them, and just mark the ones that didn't work as being broken, that would be a heck of a lot better "support" for 3.x. Realize that you will probably need to clean out /usr/local on the machine you use for this, and be prepared to xfer about 400M during the whole process (into /ports/distfiles); incrementally, you'll have to reclean /usr/local, so that you don't get any dependencies satisfied by side effect. When Satoshi builds the packages, he uses a cluster of 8 machines, and cleans out /usr/local after each build to ensure against accidental success. It really is a lot of work to support ports for old 3.x systems properly... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B00D8D4.CBF6050F>