Date: Sun, 03 Aug 1997 10:52:41 +1000 From: David Nugent <davidn@unique.usn.blaze.net.au> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: current@FreeBSD.ORG Subject: Re: ports-current/packages-current discontinued Message-ID: <199708030052.KAA17855@unique.usn.blaze.net.au> In-Reply-To: Your message of "Sat, 02 Aug 1997 17:06:07 MST." <17040.870566767@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> What features in tcl8.0 are required for a running FreeBSD system? >> Why is it essential that tcl be present in the base system AT ALL? >> What benefits are there in tcl being present here instead of being >> built by the ports/packages system? > >OK, these are all good questions. I will attempt to answer some >of them. > >1. TCL needs, *at some point* (and note that the current move was > rather premature, but let's not debate that here) to be part of > the base system so that the installation tools can use it. > We do intend on being heavy users of TCL, if not right this minute > then in the future. > >2. If it were in ports, we'd have a build problem since you wouldn't > be able to build /usr/src/usr.sbin/setup (not existant yet, but > it will be) without first building and installing a port. This > would break the world target. > >Now the obvious "answer" is to somehow integrate ports with things >that depend on it in /usr/src No, wrong answer, imho. This makes things way too complex. I already suggested a better solution to this a few weeks ago in private email, in which I cc'd you. The discussion, if you recall it (I never saw any reply from you, so I can only assume you read it) was originally about ncurses. It seems that ncurses is used by libdialog, and the only thing that seems to use either in our tree is sysinstall. Our ncurses is at version 1.8.4 dated October 1994, yet the current vendor version is 4.1. Again, we have this disparity of release schedules that John mentioned. And worse, because it isn't being actively maintained, it gets mouldy and ports depending on libncurse run into problems (ever tried installing a newer version of ncurses? I have, and it ain't pretty). I suggest that sysinstall and the release tools do not belong under src/ in the repository. They belong in a separate place, say "release/", and don't even need to track the same CVS tags. 95% of the commits you do on sysinstall are to all three branches, which I'm sure must be a headache for you. Certainly, the target for sysinstall needs to be modified based on release version, but you can handle this using makefile and preprocessor tags rather than CVS revisions (which is infinitely more complex to maintain, I'm sure). Now, if you want to move all of sysinstall's dependancies out to a separate tree, just like doc, you free the base system of quite a bit of cruft. sysinstall is built static, yet we have shared libs in our tree that nothing uses, unless they are built from ports. Shouldn't libncurses (shared lib) be therefore linked from /usr/local/lib? Is it just me, or does anyone else see the logic here? Why do we have things like libncurses and libdialog in our tree if (a) nothing uses it except sysinstall, and (b) it hasn't been updated in *years* (well, ncurses was updated recently, but this is incidental and I understand that only one vendor imported file was brought into HEAD anyway, so we're still well out of date regardless). If tcl is there for sysinstall or the Son Of Sysinstall, then clearly some restructuring is required. Now, you can have whatever you like as dependant bits under, say, release/, and you don't need to add all these bits to the world target which just gather dust after a few months. They can gather dust all they like under release/, since sysinstall no doubt depends on them and maybe these particular versions of them, but they aren't installed onto a new system, which is then free to use the ports/ packages system to install and maintain up-to-date rleases. "make release" is a separate phase from world anyway, and should logically be separated from the entire make world process. Or perhaps I'm missing something else in the larger picture. Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708030052.KAA17855>