From owner-freebsd-current Sun Aug 3 19:35:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA06033 for current-outgoing; Sun, 3 Aug 1997 19:35:34 -0700 (PDT) Received: from unique.usn.blaze.net.au (root@unique.usn.blaze.net.au [203.17.53.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA06024 for ; Sun, 3 Aug 1997 19:35:25 -0700 (PDT) Received: from unique.usn.blaze.net.au (davidn@local [127.0.0.1]) by unique.usn.blaze.net.au (8.8.6/8.8.5) with ESMTP id MAA12257; Mon, 4 Aug 1997 12:35:06 +1000 (EST) Message-Id: <199708040235.MAA12257@unique.usn.blaze.net.au> To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG Subject: Re: ports-current/packages-current discontinued In-reply-to: Your message of "Sat, 02 Aug 1997 16:50:25 MST." <16924.870565825@time.cdrom.com> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Date: Mon, 04 Aug 1997 12:35:05 +1000 From: David Nugent Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> Agreed, emphatically... But there _was_ no debate on this issue, at >> least none in a public forum. Tcl8.x just appeared out of nowhere. > >I think it's an acknowledged point that this could have been handled a >lot better, and it's my hope that we can still come to some agreement >as to how to handle this now, I'm just trying to keep everyone's back >fur reasonably smoothed down in the meantime or we're only going to >spend the next week shouting at one another. Take it from someone with >far too much experience with the latter. Ok. I hope my own whinging isn't being interpreted as "yelling". I'm really just trying to raise the issues involved and actually discuss it "rationally", if such is possible. You mentioned earlier that moving release into its own top-level tree would be a problem, but other than having to get users (the very very small minority of whom need to build their own sysinstall or package a release) to cvsup a "release-all" distribution, I see that movement as a major win with a very large number of users. This is simple cost vs. benefit. IMHO, this is probably bogus anyway - we already handle "secure", "eBones" and other similar distributions in a manner that users can seem to get a handle on without too many problems. Adding a distribution into an existing cvsup file takes 5 seconds, and most of that is waiting for /usr/bin/vi to load. :) If/when sysinstall experiences the metamorphasis that you mentioned into one or more administrative tools, perhaps it is better to leave it there under src. Or maybe not, I'm not so sure that these tools will have to be bound to releases and CVS tags and that, like sysinstall, they track the entire system regardless of branch. Please, think about it. Personally, I don't even care where it is in the repository. What I am concerned about is why and where things get installed. If components are only used by the install and administrative tools, then they should be built when building those tools, not during a "make world", and they should be only visible to the things that need them. Putting them out into the installed system is where things become problematic. In any case, if this is the only problem in such a restructuring, then perhaps some consideration could be made to move libtcl, libdialog, libncurses and whatever else these tools use into the src/release (maybe src/admin, later?) hierarchy, and only build static libraries which are linked locally and not made part of the installed FreeBSD system. It is *this* part that causes all the headaches for end users. Maybe a /etc/make.conf variable can be set to follow the current practice of installing them and shared libraries into the tree for those who wish to do so, although I can't see the ports/packages system relying on this, since this is where the conflict arises. Providing it should be relatively cheap in any case,a nd I'm willing to bet that very few, if any, will actually use it. I'm quite prepared to do all of the work involved if you wish to go ahead with this. I'll also be happy to test it by building a release and so on. Just say the word. Yes, it is *that* much of a headache for myself and others. :-) Like I said, I don't care about bloat. What I'm attempting to look at is how to resolve the problems from the user-end side, and ultimately simplify things so that FreeBSD isn't stuck half in a time warp from 1994 and earlier with large quantities of stale and unsupported software in its default binary distribution as we do at the moment. Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/