From owner-freebsd-arch Sat Jul 6 10: 9:48 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C4BE37B400 for ; Sat, 6 Jul 2002 10:09:41 -0700 (PDT) Received: from llar.net.uniovi.es (llar.net.uniovi.es [156.35.11.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A758743E31 for ; Sat, 6 Jul 2002 10:09:40 -0700 (PDT) (envelope-from sobrado@string1.ciencias.uniovi.es) Received: from CONVERSION-DAEMON.llar.net.uniovi.es by llar.net.uniovi.es (PMDF V6.1 #39514) id <01KJSA9ZQPQO00AFK3@llar.net.uniovi.es> for arch@freebsd.org; Sat, 06 Jul 2002 19:09:33 +0200 (MET) Received: from string1.ciencias.uniovi.es (string1.ciencias.uniovi.es [156.35.97.40]) by llar.net.uniovi.es (PMDF V6.1 #39514) with ESMTP id <01KJSA9XDQNI00AAAQ@llar.net.uniovi.es>; Sat, 06 Jul 2002 19:09:30 +0200 (MET) Received: from string1.ciencias.uniovi.es (sobrado@localhost [127.0.0.1]) by string1.ciencias.uniovi.es (8.11.1/8.11.1) with ESMTP id g66H9UE00832; Sat, 06 Jul 2002 19:09:30 +0200 Date: Sat, 06 Jul 2002 19:09:30 +0200 From: Igor Sobrado Subject: Re: software in /usr/contrib In-reply-to: Message from Dag-Erling Smorgrav "of Sat, 06 Jul 2002 18:13:39 +0200." To: Dag-Erling Smorgrav Cc: Igor Sobrado , arch@freebsd.org Message-id: <200207061709.g66H9UE00832@string1.ciencias.uniovi.es> MIME-version: 1.0 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Igor Sobrado writes: > > Moving some software in *strong evolution* (bzip, gzip, zip, Perl, > > and Tcl/Tk) to /usr/contrib will be useful to avoid some problems > > that we saw in the last years in other Unices like Solaris. A > > description of some of those problems is in [bin/40222]. > > I don't understand what problem you are trying to solve. > I am sorry, I have not explained the problem because I show it some days ago in a problem report. The problem is that some externally maintained software is provided in /usr/bin (a directory that is required for all users and that cannot be removed from the PATH environment variable). I am speaking about Perl, and some compression tools, mainly. But /usr/contrib does not provide only perl, gzip, bzip2, and [un]zip, it provides too expect, Tcl/Tk and other software too when available. All those packages are in a strong evolution (Unix has some tools that are not in a strong evolution at present, but only changed when bug fixing.) and should be provided in another directory. Sun has made a mistake providing those binaries in /usr/bin. For example, we (as Solaris users) had been problems in the last year with bzip2 (the one provided with Solaris has a race condition that sometimes erases not only the file that is being created, but the uncompressed file too), and the zlib. As these binaries are in /usr/bin users have not a chance to remove them from their paths. What is the right behavior in this case? Replace them with most recent ones? It will change the operating system behavior and, if some packages depends on those binaries -like software installing tools that manage compressed files or administrative scripts written in perl- they can break when changing those binaries. Installing new releases of those binaries in /usr/local/bin (BSD) or /opt//bin (SVR4.x) does not seems a good workaround. In this case, some users will run the new ones (if they have /usr/local or /opt paths before /usr/bin) or the older ones, making the behavior of the operating system really unpredictable even locally. Replacing those binaries will make it most difficult to establish a problem for the FreeBSD technical staff around the world. Some Unices, like BSD/OS and HP-UX, have a different approach to solve this problem. They provide that software in other directories, more exactly in /usr/contrib/{bin, lib, sbin, ...} Those versions of that software can be hard-coded in the binaries (like bzip2 can be hard-coded in a software installation utility) or system scripts (that can be run under the right perl version) but will not be required for normal users, that can choose not to have /usr/contrib on their paths. Links in /usr/bin are possible, these links can be removed without removing the software used by those scripts. Some of us need not recent releases of some software (the *BSD offers the most recent releases available in most cases!) but customized software (like a Tcl version modified to build the MICE video-conferencing tool from source, or a modified compression tool). > Both of these, as well as Solaris, are commercial OSes distributed in > binary form, where OS upgrades are done by applying binary patches or > installing a new binary release on top of the existing system, once > every couple of years or so. FreeBSD is an open-source OS with a > completely different distribution model, where upgrades are done by > building a new system from updates sources, and happen quite > frequently. You can't really compare the two. > Agreed. But sometimes we do not need a most recent release, but a customized one. And all that software is in a very strong evolution. Unix [un]compress, sed, mail, mailx, or ldd, for example, will not change a lot in the next years (at least we think that these commands will not change!). There are not important changes expected for these tools, only bugfixes. But some of us need modified releases of tools like perl, Info-ZIP, or Tcl/Tk. It should be good to provide those tools in /usr/contrib, where will be available for the operating system (for example as hard-coded interpreters in shell scripts) but users can choose not to add them to their paths. Or, at least, it should be nice to allow users not to install them if they do not want. I think that moving that software (that is in strong evolution yet) to /usr/contrib is not a POLA violation. And most important, links can be provided in /usr/bin to hide those changes to end-users. I propose that change because I think that it will be reasonable and will improve that operating system quality. Thanks a lot for reading my proposal! 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