Date: Sat, 06 Jul 2002 19:09:30 +0200 From: Igor Sobrado <sobrado@string1.ciencias.uniovi.es> To: Dag-Erling Smorgrav <des@ofug.org> Cc: Igor Sobrado <sobrado@string1.ciencias.uniovi.es>, arch@freebsd.org Subject: Re: software in /usr/contrib Message-ID: <200207061709.g66H9UE00832@string1.ciencias.uniovi.es> In-Reply-To: Message from Dag-Erling Smorgrav <des@ofug.org> "of Sat, 06 Jul 2002 18:13:39 %2B0200." <xzp3cuwsuks.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
> Igor Sobrado <sobrado@string1.ciencias.uniovi.es> 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/<vendor>/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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207061709.g66H9UE00832>