Date: Sun, 03 Aug 1997 07:33:39 +1000 From: David Nugent <davidn@unique.usn.blaze.net.au> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, asami@cs.berkeley.edu (Satoshi Asami), andreas@klemm.gtn.com, ports@FreeBSD.ORG, current@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: ports-current/packages-current discontinued Message-ID: <199708022133.HAA14498@unique.usn.blaze.net.au> In-Reply-To: Your message of "Sat, 02 Aug 1997 11:32:38 MST." <15386.870546758@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> I have seen in the FreeBSD project since my involvement. I can count the >> number of such incidents I've witnessed in the last couple of years on one >> hand, so it's not like the project is infested with stupidity. It was >> very ill-considered, and Satoshi's position here is critical. That he >> apparently got no say in this is incredible, to say the least. It seems >> obvious to an outsider that there are some very fundamental communication >> problems within the core team. Seeing this fixed is even more critical >> than where tcl or perl happen to reside. > >What most people here don't understand is that there was very fierce >debate about this behind the scenes for some time before it was done, >and what started as a TCL debate blew up into a whole "should FreeBSD >have everything unbundled, from the compilers to perl, or should it >bundle all the high level tools so that other system tools can be >written which depend on them?" sort of fracas. One man's useful tool >is another man's wasteful, unnecessary bloat, it seems, and rather [..] Yes, yes, yes. But all completely besides the point. I don't care one way or another about "bloat". It is irrelevent to the point I was making. "Bloat" is subjective, as you point out, but it has nothing to do with how tools are updated and integrated into the system. Tools which are imported into the base system are *necessarily* more static, because of the very real concerns that have caused problems here. They won't change as often, they can't change as often, else we should by rights be carefully following perl development IN THE SOURCE TREE rather than having not only an obsolete version of perl, one completely unsupported and with seriously security bugs, and one which hardly anyone uses anyway. Tcl, until this apparently unpopular import, was at least in a better position than that. I've said before that perl4 must die. I don't particularly care whether it is imported into the source tree or left as a port. It is stale, it is old, it is obsolete and completely unsupported. It has bugs, limitations and security holes. It must go. Period. My only concern about importing a current version into the source tree is the same as tcl - what guarantees are there that this will be kept up to date? The ports system, in spite of its faults and shortfalls, *works*, and works extremely well, mainly because of the efforts of porters and Satoshi's management. But I hardly need to point this out to you of all people. The ports system integrates third party software into the base system seemlessly, provides upgrade paths and has people actively supporting (the most popular packages, anyway) and updating their favourite apps. Sure, there are mistakes there, like the recent apache vs. apache current debate, but these are far more easily handled in the less expensive and more low-maintenance system that ports has been designed to handle. Again, this has nothing to do with any "bloatist" point of view, nor is it anti-perl or anti-tcl either - I use both daily and enhance systems constantly with both of them. BUT: How is tcl essential to a working FreeBSD environment? How is perl, for that matter, other than a few scattered scripts which can and do work quite happily with current versions of perl (and can easily be replaced with /bin/sh scripts anyway)? Why are we nailing ourselves to versions of third party software which are prone to become stale and unmaintained? Why can't the ports system be used for them? >Once you start with TCL, it will *not* stop there - I can only assure >you of that. Perl will follow immediately behind, as will much other >stuff (yes perl fans, there are many out there who consider your >favorite utility language an evil, bloated monster which should not be >bundled with FreeBSD at all). What we have now is a rough state of Surely, you're not suggesting that just because something is in not in the FreeBSD base system that it is "evil"? Oh come on, this is such a childish attitude I can't believe I'm hearing it. The question is not how large a package is, it is how useful it is in the base distribution - how dependant upon it a FreeBSD system is in installation and setup, and how integrated it is into the system. Neither perl nor tcl have any grip in the system where they could be considered so essential that FreeBSD will not run without them. It is more *appropriate* that they be maintained, integrated and - ESPECIALLY - kept current via the ports system. This is a major PLUS for users, not the opposite as you seem to be assuming. perl4 in the tree is living proof of exactly where we end up with the approach that is being taken. >equilibrium between the two sides (who are fundamentally at odds as to >what constitutes a reasonable bundling policy) and while TCL may be >causing some grief, I think the bloatists are content with that state >of affairs and nothing else is on the bundling horizon that I can see. >Nuke TCL and you will swing the balance in the other direction, with a >lot more than just TCL biting the dust as a result. Maybe that's not >such a bad thing, but just so you understand how much of a "linchpin" >issue this one is. No, I understand the issue well enough. But I think it is irrevelent. Having "current" versions of things in ports and "old" things in the tree is not only annoying, it is downright ridiculous. The opposite is almost as bad. I would quickly add that any generalisation here is dangerous - you have to consider the benefits of things being integrated into the source tree vs. the costs of possibly becoming stale. It is far easier to keep our cvs "hands" of a third party package and integrate it via the ports system. Diffs between a distribution and the "FreeBSD version" are absolutely plain without even having a source repository around. Things like bind, gcc, gdb etc. are a completely different ballgame. So, no, I don't see this as any sort of weighted argument. You can cry about bloat all day, and I simple don't care. That point of view misses the issue entirely. tcl is a major headache in terms of multiple version operability. Perl is likewise (do you do much perl debugging?). I'd live silently with these problems if the benefits outweighed the cost in terms of hassle, but to me, it just isn't worth it. 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?199708022133.HAA14498>