Date: Sun, 07 Jul 2002 11:18:04 +0200 From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es> To: Terry Lambert <tlambert2@mindspring.com> Cc: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>, Dag-Erling Smorgrav <des@ofug.org>, arch@freebsd.org Subject: Re: software in /usr/contrib Message-ID: <200207070918.g679I4E06788@string1.ciencias.uniovi.es> In-Reply-To: Message from Terry Lambert <tlambert2@mindspring.com> "of Sat, 06 Jul 2002 15:16:34 PDT." <3D276C42.67C25814@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I believe when he says "in a strong evolution", he actually means > "undergoing active developement". > Yes, of course! It is exactly what I wanted to say. My English skills are not as good as they should be. All that software is in a very active development with too frequently changes. And it can be a problem for FreeBSD as it is now for Solaris. > The problem he appears to be trying to solve is that these things > tend to change very quickly, without any FreeBSD control over > their size, shape, or direction. > Exactly! That is the problem. An additional problem with all those things that change very quickly is that, sometimes, there are not only stable and development releases, but also some different branches. I need a modified Tcl/Tk (OTcl from MIT) to build the ISI/Berkeley Network Simulator. Same happens with all the video-conference at MICE project. That software requires another modified release of that software. It should be nice to provide a release of that software under active development as a part of FreeBSD. But, IMHO, it should not be in /usr/bin. There is not a problem hard-coding the path to those programs in scripts and binaries when required, but users should have a chance to install their own customized versions of that software, or even another release (either more recent or more ancient) if they need it. > This was the initial justification for the removal of Perl in the > based system, and the seed of the ongoing dicussion entitled > "Removing perl in make world". > I am new to the *BSD world (I come from the Solaris, HP-UX and IRIX world). I did not know that discussion about Perl. By the way, I have checked that my fresh installation of FreeBSD 4.6-RELEASE includes Perl (an old Perl, not the latest stable release) in /usr/bin. What was wrong with my installation? I have not added it from the ports. And I use /usr/local (in the BSD flavors of Unix) to install all the optional software. > Igor is saying that there are other tools which are obtained from > thir parties which should also atl least be moved to "controib", > if not banished from the system to a port/package. > Well... "banish" a tool to a port seems dangerous! Moving Perl (that is included with 4.6-RELEASE), bzip2, gzip, and other tools to /usr/contrib/bin seems reasonable. In any case, it is possible to provide a link to those binaries in /usr/bin. Some tools (and compression tools are good examples) can be useful for the operating system (ports probably require those tools). And it is possible to write administrative scripts in Perl (Solaris has some of those scripts now), that can be *required* for the operating system to run. There is nothing wrong in that approach, but users should have a chance to install their own tools. Other software (Info-ZIP) supports a lot of extensions not provided either because there are of no use for most users (like the ability to manage OpenVMS versions ";x" in files) or because there are some license restrictions on the algorithms. But some users need those fully functional [un]zip releases too. > For some tools, this makes sense. For other tools, this is very > dangerous... and here's why: > > FreeBSD has been steadily giving away control of base system > components to third parties. Any time it takes a BSD verion > of a program, such as "tar", and replaces it with a GNU or > other vendor's equivalent, even if it's done for good reason, > then it sets up a situation like the one Igor is concerned > about. > > I think that he's right for some tools; they simply don't belong > in the base system (e.g. "bzip2" is not in specified by POSIX or > the Sinugle UNIX Specification). But for other things, where > there is not a BSD equivalent, or where the BSD equivalent has > been intentionally abandoned, it doesn't make sense. > Agreed! I *never* wanted, we say, Gnu tar moved to /usr/contrib even if it is maintained by third parties. It is very dangerous to move something like tar or cc out of /usr/bin even providing a link to those binaries. I was speaking only about changing some software that other Unix vendors are providing in /usr/contrib to that place. Both, BSDi (now Wind River) and Hewlett-Packard (now Compaq) have the same set of packages in (/usr/contrib), with very small differences: bzip2, gzip, Perl, Tcl/Tk, Expect or (why not?) nmh. But I was not speaking about moving Gnu tar or gcc (I think that at least gcc will be very difficult to replace with a native BSD C compiler!). Those programs are a part of any Unix distribution. > I don't claim to have a litmus test that would let you pick in > every case; if this idea goes forward, it should be with caution. > I agree with you, Terry. All changes should be adopted with caution. But we have a reference to follow in the BSD/OS and HP-UX operating systems. Thanks a lot for your feedback. You have explained some very important points, like what software can (and cannot) be moved, and what was the idea behind that proposal. Cheers, Igor. -- Igor Sobrado, UK34436 - sobrado@acm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207070918.g679I4E06788>