Re: Confusing error messages from shell image activation
David O'Brien writes: On Mon, Dec 11, 2000 at 02:35:43PM -0500, Richard J Kuhns wrote: /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.2" not found /prog/applix/axdata/axmain: Operation timed out Blah. :-( Applixware depends on the compat3x distribution it seems. Can you install compat3x and see if it now runs? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX Yes, it now runs. So it looks like we have the following scenario: 1. Applixware v5.0 depends on the compat3x distribution, so it won't run on an out-of-the-box FreeBSD 4.2 system. I hadn't noticed that before because I originally installed it on a machine that went through a phase running 3.x, so the older libraries were still there. 2. Applixware v5.0 can be installed anywhere you like as long as you use the package, but you have to manually edit a shell script. Eg, PREFIX=/opt pkg_add -p $PREFIX applix-5.0.tgz Then edit $PREFIX/bin/applix and make sure APPLIX_HOME is set to $PREFIX/applix. By the way, v5 seems to be much more responsive than v4. Purely subjective, of course, but I've had a couple of comments on it. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Tue, Dec 12, 2000 at 10:21:49AM -0500, Richard J Kuhns wrote: 2. Applixware v5.0 can be installed anywhere you like as long as you use the package, but you have to manually edit a shell script. Eg, It is probably too late to fix this, but the script should use this: if ! PREFIX=$(expr $0 : "\(/.*\)/bin/$(basename $0)\$"); then echo "$0: Cannot determine the PREFIX" 2 exit 1 fi (or maybe only do this if PREFIX isn't in the env) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 11:42:37PM -0600, Mike Meyer wrote: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Mine lives in /usr/opt just fine. What signs do you have of it not liking being out of /usr/local ? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. Yes changing the policy is something different. IMHO, it will never been done -- way too much momentum behind it now. BUT, I wish people would understand the basic premise and stop bringing up what this and that used to 10 years ago. People doing that are *missing* the issue. NetBSD got it right. BSDi(BSD/OS) got it right. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. Packages (ie, those Satoshi builds) no. Building the port yourself, yes. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:58:21PM +1100, Andrew Reilly wrote: I agree that PREFIX/LOCALBASE should work: you can't legislate taste. I'm going to keep it to /usr/local and /usr/X11R6, though, thanks all the same. Its been acknowledged that we really should not be installing ports into /usr/X11R6 -- that is for X. But Imake is hard to make it DTRT. :-( -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. The install logfile: CopyFile: /cdrom/applix - /opt/applix/applix CopyFile: /cdrom/axart/alphabet/a1.ag - /opt/applix/axart/alphabet/a1.ag ... ... ... CopyFile: /opt/applix/axdata/axlicensedemo - /opt/applix/axlocal/axlicensedat CopyFile: /opt/applix/axdata/eng/ax_prof4.eng - /opt/applix/axdata/ax_prof4 The location was an install question from memory. This is version 4.42. Maybe Version 5 different? -- tonym (who uses /usr/local for ports/packages, /usr/host for handbuilt stuff and /opt for really big packages that have their own internal hierachy - I am so confused ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Tony Maher writes: On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. Really?! I have it installed in /opt/applix and I dont think there are any symlinks anywhere in /usr/local for it. It works fine. The install logfile: CopyFile: /cdrom/applix - /opt/applix/applix CopyFile: /cdrom/axart/alphabet/a1.ag - /opt/applix/axart/alphabet/a1.ag ... ... ... CopyFile: /opt/applix/axdata/axlicensedemo - /opt/applix/axlocal/axlicensedat CopyFile: /opt/applix/axdata/eng/ax_prof4.eng - /opt/applix/axdata/ax_prof4 The location was an install question from memory. This is version 4.42. Maybe Version 5 different? Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Note the hard-coded APPLIX_HOME. There were other problems trying to install somewhere else, but I'm afraid I don't remember details. I played with it for a little while, but gave up and left it in /usr/local :(. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert scribbled: | For foreign or not-so-foreign packages and software, I've seen | /usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I | worked at was even pedantic that /usr/contrib was for externally | generated software and /usr/local was for software written and/or | maintained locally. I've also worked in environments where different | directory structures implied the level that the IS guys intended to | support the software. I know I should not jump into this bikeshed. But IMHO, whereever we have our packages install to, we should also place our ports metadata (/var/db/pkg) and the ports skeleton in the same place, preferably a mountpoint. This allow me to switch between different sets of installation with ease. (No, please do not tell me to change PREFIX and mv /usr/local /usr/local.bak) With this setup, I can rm -rf whatever place this goes, and have a clean system again. For the ports developers, we can switch between configurations without the need for chroots or jails taking up disk space. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 09:07:27AM -0500, Richard J Kuhns wrote: Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Again lack of details.. :-( EXACTLY what is this file you are showing us? Both my of my Applixware 4.42 and 5.0 installations have a real binary named `applix' in the root of the install directory. I installed 4.42 from the Walnut Creek CDROM CD of it. I installed 5.0 on the first tarball package of 5.0 BSDi made (that wasn't released to the public). So we also need to know how you got 5.0 (ie, what media are you using). Something may have easily changed between what I installed and what BSDi is now shipping. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
David O'Brien writes: On Mon, Dec 11, 2000 at 09:07:27AM -0500, Richard J Kuhns wrote: Yes, it's definitely different. No matter what you say when installing, `applix' is: #!/bin/sh APPLIX_HOME="/usr/local/applix" export APPLIX_HOME exec $APPLIX_HOME/applix "$@" Again lack of details.. :-( EXACTLY what is this file you are showing us? Both my of my Applixware 4.42 and 5.0 installations have a real binary named `applix' in the root of the install directory. I installed 4.42 from the Walnut Creek CDROM CD of it. I installed 5.0 on the first tarball package of 5.0 BSDi made (that wasn't released to the public). So we also need to know how you got 5.0 (ie, what media are you using). Something may have easily changed between what I installed and what BSDi is now shipping. OK. In my current installation, it's /usr/local/bin/applix. I installed from the CD the Walnut Creek/BSDi shipped me (Applixware Office for FreeBSD v5.0). I just tried to install it from scratch on a new machine running 4.2-RELEASE. If I cd to /cdrom/Applix5 and run ./install, I'm not offered a choice concerning where to install -- it goes under /usr/local. I just tried `pkg_add -v -p /opt applix-5.0.tgz'. It then put things under /opt, but /opt/bin/applix was the file I listed above with the hardcoded "/usr/local/applix". When I changed it to "/opt/applix" and tried to run it, I got /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.2" not found /prog/applix/axdata/axmain: Operation timed out Since there's not a libstdc* of any sort under /opt/applix, either something didn't get installed correctly or applix was compiled using an older version of the shared library. At this point, I have some Real Work to do. If there's something else you'd like me to look at, let me know. It may take me a few hours, though. -- Richard Kuhns [EMAIL PROTECTED] PO Box 6249 Tel: (765)477-6000 \ 100 Sawmill Roadx319 Lafayette, IN 47903 (800)489-4891 / To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 02:35:43PM -0500, Richard J Kuhns wrote: /usr/libexec/ld-elf.so.1: Shared object "libstdc++.so.2" not found /prog/applix/axdata/axmain: Operation timed out Blah. :-( Applixware depends on the compat3x distribution it seems. Can you install compat3x and see if it now runs? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, 11 Dec 2000, Michael C . Wu wrote: I know I should not jump into this bikeshed. But IMHO, whereever we have our packages install to, we should also place our ports metadata (/var/db/pkg) and the ports skeleton in the same place, preferably a mountpoint. This allow me to switch between different sets of installation with ease. (No, please do not tell me to change PREFIX and mv /usr/local /usr/local.bak) With this setup, I can rm -rf whatever place this goes, and have a clean system again. For the ports developers, we can switch between configurations without the need for chroots or jails taking up disk space. I would agree strongly with this. Something like: /usr/ pkg/ bin/ db/ -- /var/db/pkg, why is that in /var anyway? it's not exactly temporary or transient information. etc/ include/ info/ lib/ libexec/ man/ sbin/ share/ src/ -- /usr/ports/* This would make it easy for one to return his system to a pristine state. Simply removing /usr/pkg would get rid of all third-party information. It makes sense to package this entire directory together. If one wanted a fresh system he could remove /usr/pkg, do a make world, and tell mtree to remove anything not in the system mtree file. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
Michael C . Wu [EMAIL PROTECTED] types:
I know I should not jump into this bikeshed. But IMHO, whereever
we have our packages install to, we should also place
our ports metadata (/var/db/pkg) and the ports skeleton in the
same place, preferably a mountpoint. This allow me to switch
between different sets of installation with ease. (No, please
do not tell me to change PREFIX and mv /usr/local /usr/local.bak)
With this setup, I can rm -rf whatever place this goes, and
have a clean system again. For the ports developers, we can
switch between configurations without the need for chroots or
jails taking up disk space.
Ok, I can see wanting that. And I can see how it would be handy for
ports developers. But my instant reaction was "yuch". The reason for
that is that, unlike the contents of ${PREFIX}, the contents of the
ports metadata is *not* generally recreatable from the /usr/ports
tree. This means it's more precious, and you might want to back it up
more frequently, etc.
While some method for ports developers to move the metadata (say an
environment variable) should be provided, I think the above is a good
reason for leaving the default as is.
BTW, pkg_add (at least) honors the environment variable PKG_DBDIR to
set the location of the ports metadata directory. Is there some reason
you can't just set that to /usr/local/etc/db/pkg or some such?
Final comment - I wish more ports developers *would* set PREFIX.
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [current] Re: Confusing error messages from shell image activation
On Mon, Dec 11, 2000 at 12:37:54AM -0500, David Gilbert wrote:
... but /usr/pkg supplanting /usr/local is one of the things that I
like about NetBSD.
/usr/pkg sounds a little bit odd ... ( at least for my ears).
Why not choose what Solaris uses (/opt) ?
It would be an advantage, when designing filesystem size of your OS,
that now you would have two completely separate paths /usr and /opt.
Installing ports in /usr means, having a too large /usr or to mount
a new filsystem under /usr (/usr/local). Mounting an fs under a mounted
fs I dislike much ...
What about the following installation hierarchy
/opt/category/port/{bin,etc,include,lib,libexec,man,sbin,...}
with symlinks to
/opt/{bin,etc,include,lib,libexec,man,sbin,...}
This would be an advantage for larger packages, as now you can very
easily see, what belongs to a package and what not.
Additionally you can install multiple versions of a port at the
same time, and slowly migrate the configs/settings to the new port.
For critical server application this scheme gives you more fine grained
control, concerning what version to use and you can easily go back if
you need...
pkg_version -c is cool, but it simply overwrites your working port,
keeps the configs, but pray, that everything runs.
The above suggested symlinks are a needed evil, so that you again only
need one place for manpages and binaries...
It gives you a lot more directories and symlinks, but when installing
it on a different filesystem, I think you can very easily live with
it, concerning the better control over installed packages.
Another plus is, that you now see _directly_, what files, config-files,
etc belong to a software, that is huge and complex ...
packages like KDE wouldn't f*up /usr/local as they do now.
Teaching KDE to install in /usr/local/kde is complex and I lost
fun doing so when I frist tried a year ago...
Andreas ///
--
Andreas Klemm Powered by FreeBSD SMP
Songs from our band 64Bitshttp://www.apsfilter.org/64bits.html
My homepage http://people.FreeBSD.ORG/~andreas
Please note: Apsfilter got a NEW HOMEhttp://www.apsfilter.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Mike Meyer wrote: Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. Honestly, let it go. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
[Please watch your carbon copies!] On Sun, 10 Dec 2000 09:37:53 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. No software that is a part of FreeBSD installs in /usr/local. As a convenience feature, FreeBSD includes software from third parties which does so, and in most cases has always done so by default. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Daniel C. Sobral [EMAIL PROTECTED] types: Mike Meyer wrote: Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I don't expect to get it changed until enough people are aware that it's a problem. Occasional rounds of consciousness-raising are required to make that happen. That may not happen until the old guard dies of old age; I asume we both want FreeBSD to be a viable OS that long. Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Mike Meyer writes: : Corrections first: The only place where FreeBSD fails to follow FHS : (in my quick perusal of it) is in putting packages in /usr/local : instead of /opt. You can't blame that part of FHS on Linux - I have as : yet to see a Linux distro or package do it that way. No, this bit : comes from commercial vendors, where it's also steeped in years of : tradition. Not as many as you might think. /usr/local predates /opt by several years. I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. : Rant second: FreeBSD *violates* years of traditions with it's : treatment of /usr/local. /usr/local is for *local* things, not add-on : software packages! Coopting /usr/local for non-local software creates : needless complexity and confusion, which of course leads to needless : pain. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Garrett Wollman [EMAIL PROTECTED] types: On Sun, 10 Dec 2000 09:37:53 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. No software that is a part of FreeBSD installs in /usr/local. As a convenience feature, FreeBSD includes software from third parties which does so, and in most cases has always done so by default. Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Mike Meyer writes: If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. If you remember v6 and v7, then please enumerate the packages which installed in /opt on those systems. All "packages" I am aware of from the v6/v7 era installed in /usr or in /usr/local, although I am sort of fuzzy on the exact derivation of /usr/local at this point in time. I do recall having a /usr/local on my V6 PDP-11/40, but it could have been contamination leaking over from the 32V system. I do remember the abomination of /usr/ucb which put binaries in /usr/ucb but also included /usr/ucb/lib, etc. I always hated that structure. I know that we made extensive use of /usr/local in 1983 on 4.1bsd, especially in installing software taken from Usenet, so I think that /usr/local really started with extensive use of Usenet distribution, which was coincident with wide-spread use of BSD on VAXen. As far as I remember, I never encountered the use of /opt until Solaris. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 10:13:42AM -0600, Mike Meyer wrote: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. You are really reaching here. Contributed software that the FreeBSD Project has chosen to integrate, i.e., Perl, Sendmail, just to name a few, are integrated tightly and installed in /usr/bin, etc, not in /usr/local. Ports, on the other hand are installed in /usr/local or /usr/X11R6. You seem to mis-understand that a FreeBSD port is basically a set of patches and a source fetching mechanism that is included with FreeBSD as a convenience for building and installing third party software. The actual software that gets built and installed is _not_ part of FreeBSD. This is not a rationalization. I for one would be really upset if when I installed a Port, it's binaries started getting dropped into /bin, /usr/bin, etc. I suspect many others would too. I'm really not exactly sure what you are complaining about. For example, the last time I built Emacs for Solaris (several years ago admittedly), by default it installed itself into /usr/local. If you install Emacs onto FreeBSD, it goes into /usr/local. The behaviour is the same. Are you proposing that since FreeBSD provides a set of patches so that Emacs builds cleanly, that it should therefore install it somewhere other than /usr/local? -Brian -- Brian Dean [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Mike Meyer [EMAIL PROTECTED] writes: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. Your argument doesn't make much sense to me. So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? If I grab a sawfish FreeBSD package from the sawfish website, where should that install? /usr/local? /opt? /usr/pkg? Third party software is third party software, no matter who compiled and packaged it. If I install a package of third-party software, the end result should be about the same as if I compiled and installed it by hand -- the packaged software is a convenience, not a fundamentally different entity. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 09:37:53AM -0600, Mike Meyer wrote: Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I'm fairly sure that some of the software distributed by SGI on their unsupported free software media does this. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, 10 Dec 2000, Brooks Davis wrote: On Sun, Dec 10, 2000 at 09:37:53AM -0600, Mike Meyer wrote: Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I'm fairly sure that some of the software distributed by SGI on their unsupported free software media does this. Since I'm sitting in front of an SGI answering this email I'll throw in that it's actually put in /usr/freeware. It's quite annoying. I much prefer FreeBSD's /usr/local. My path under IRIX has to include: /usr/bin/X11:/usr/local/bin:/usr/freeware/bin:/usr/gnu/bin:/usr/ucb:/usr/bsd:/usr/etc:/usr/gfx to encompass the various places software installs itself. It's so much nicer under FreeBSD to have one location to worry about third-party binaries showing up. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Nat Lanza [EMAIL PROTECTED] types: Mike Meyer [EMAIL PROTECTED] writes: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. Your argument doesn't make much sense to me. Ok, let's walk through the details (bottom of the letter). So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? It should go where you want it to. /usr/local is a bad place because of it's tradition of being for locally maintained software. If I grab a sawfish FreeBSD package from the sawfish website, where should that install? /usr/local? /opt? /usr/pkg? Not /usr/local - that's for locally maintained software. I'd rather it go on /usr, so I don't like /opt. When I got to choose, I chose /usr/opt. But anything other than /usr/local on /usr would do as well. Third party software is third party software, no matter who compiled and packaged it. That's true. But if it's packaged, it belongs in an area reserved for *packages*. FreeBSD is the only system I know of that coopts /usr/local for packages, instead of reserving it for things that are locally maintained. Whether that locally maintained software is written locally or comes from a third party is irrelevant to this discussion. If I install a package of third-party software, the end result should be about the same as if I compiled and installed it by hand -- the packaged software is a convenience, not a fundamentally different entity. That's correct. The differences aren't in the software, they are in the administrative regimen. Let's look at how you deal with FreeBSD proper, ports/packages, 3rd party software that isn't from a port or package, and locally written software. Administrative FreeBSD port/pkg3rd party local item Binary from FreeBSD FreeBSD author author Source from FreeBSD patches and author author location from FreeBSD Responsible for FreeBSD Portlocal local it building on maintainer maintainer maintainer maint- my FreeBSD box ainer requires local src No No Yes Yes configuration? Updates fromFreeBSD FreeBSD author author Patches best sent FreeBSD Portauthor author to maintainer maintainer As you can see, the only difference between locally written software and third party software is that the author in the latter case is local. Meanwhile, the primary difference between software that is part of FreeBSD and a port/pkg is that the person who takes responsibility for some part of FreeBSD is always a FreeBSD committer, whereas the person who takes that responsibility for a port/package may not be a FreeBSD committer. Sure, sometimes that person for a port is the author - but that's also true for FreeBSD. For 3rd party and local software, you always deal with the author; for FreeBSD and a port or package, you deal with an intermediary that has taken responsibility for the software on FreeBSD, who may *not* be the author. The critical difference is the "requires local src configuration" line. For FreeBSD or any of the ports or packages, I can blow away the source tree without worrying about needing it back; I can always get it back from FreeBSD again. For the same reason, I don't worry much about the binaries. For locally written software, if I lose ths source, I'm SOL. For true third party software, how screwed I am depends on how hard it was getting the thing to build on FreeBSD. As a general rule, I always save them. The binaries get the same treatment. Having to figure out which is which is *much* easier if the two are in different directory hierarchies. Clearly, a package is *not* the same as either third party or locally written software. For people who don't care about any of those differences, packages co-opting /usr/local doesn't matter. For people who do, there's PREFIX - except it doesn't work very well, and can't work for binary builds (and with the CDROM set no longer having distfiles on it, that's a major PITA). mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 12:12:59PM -0500, Nat Lanza wrote: Your argument doesn't make much sense to me. It make total sense to me. So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? Correct. Third party software is third party software, no matter who compiled and packaged it. No, the issue is one of "preciousness". In other words why backup software that I can just do `pkg_add' to get again? Or if I want to easily start from scratch and update all my FreeBSD Packages? ``rm -rf /usr/pkg'' followed by a bunch of ``pkg_add -r'' is way easy. Similarly to me not backing up /usr on a FreeBSD machine. Why bother as I have a Live-FS cdrom I can get a copy from. Nor many people backup the /home/ncvs directory (see PHK's message about this also in -current) as a simple CVSup will get you a new copy. Now scripts I wrote and software I went to the trouble to download, hacke the Makefiles to DRTR, etc.. have a *LOT* more effort put into getting them working. Thus they are more precious and are treated more dearly. Maybe even backed up. ;-) Thus there _are_ three classes of software in FreeBSD'ville. 1. lives in /usr/src and installed by `make world' 2. lives in /usr/ports and installed by `make install' or `pkg_add'. 3. locally written or obtained -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 01:18:51PM -0500, Brandon D. Valentine wrote: My path under IRIX has to include: /usr/bin/X11:/usr/local/bin:/usr/freeware/bin:/usr/gnu/bin:/usr/ucb:/usr/bsd:/usr/etc:/usr/gfx That is so bad considering the power it gives you? It only takes 2-3 lines in your dot files to check each dir and add it to your PATH if it exists. For instance on Solaris boxes I install GNU bits into /usr/gnu. Why? Because it gives you better control over what binaries you run -- remember GNU *utils replaces the systems native ones (ie, cp, rm, as, shar, etc...). Thus one can put /usr/local/bin:/usr/bin:/usr/gnu/bin as their path and have any wrapper scripts take precedence over system bits, but use the native system bits over the GNU ones if you are a traditionalist. This control is part of why it would be nice to have /usr/pkg separate from /usr/local. I've given up on FreeBSD and had to create my own /usr/treats to hold what should have been in /usr/local if the FreeBSD Packages hadn't polluted it. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
David O'Brien [EMAIL PROTECTED] types: This control is part of why it would be nice to have /usr/pkg separate from /usr/local. I've given up on FreeBSD and had to create my own /usr/treats to hold what should have been in /usr/local if the FreeBSD Packages hadn't polluted it. I went the other way, because "that's what PREFIX is for". I figured there would be less pain involved in moving a system designed to be moved than in moving random software that may or may not be so designed. After having done so for a while, it's not at all clear that was a correct decision. That this is the case says a lot about the implementation of that design, none of it good. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. : Rant second: FreeBSD *violates* years of traditions with it's : treatment of /usr/local. /usr/local is for *local* things, not add-on : software packages! Coopting /usr/local for non-local software creates : needless complexity and confusion, which of course leads to needless : pain. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. On V7 (the earliest software I have), vendor software installed itself in /usr/[bin|lib], which is IMO worse than /usr/local. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
"David O'Brien" [EMAIL PROTECTED] writes: No, the issue is one of "preciousness". In other words why backup software that I can just do `pkg_add' to get again? Or if I want to easily start from scratch and update all my FreeBSD Packages? This is an entirely reasonable argument; I don't tend to group software this way, so I hadn't thought of it like this. This is probably because in my world, we use a somewhat different model for software installation -- CMU is heavily dependent on AFS, and software tends to be installed on local machines out of backed-up AFS volumes through something like depot. So every package has its own little directory tree, and it's all merged together at install time into /usr/local or /usr/contributed or something like that. So we don't differentiate how precious software is by where it's installed -- the directories it's installed _from_ are the key bit, and the destination directories can be wiped and recreated at any time. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
In message [EMAIL PROTECTED] Nate Williams writes: : I'm aware that software was installing itself in /usr/local years : before it was installing in /opt. On the other hand, vendor software : was installing in /opt years before I ever saw it install in : /usr/local. : : Most vendor software I know pre-dates /opt, and installed itself in : /usr/local. I'm with Warner on this one, installing in /usr/local : predates /opt by many years. Before /opt, vendors always used : /usr/local, or worse they installed in /bin and /usr/bin. Yes. 4.1BSD, I think, used /usr/ucb for the hacks that ucb had done to the system. I had it in my path for years and have been considering removing it, but solaris still uses it :-( (I have an array of candidate paths for my path and only insert the ones that exist from my .cshrc file). System III with ucb hacks also had them in /usr/ucb. I forget which System that the 3b2s ran (I think it was System V r1 before there was an r2), but they had the ucb hacs in /usr/ucb. I think that software packages built from sources installed themselves into /usr/local, but it has only been about 11 years since I last logged into a 3b2 at Wollongong so I can't easily go back and check. :-) Sadly, I didn't start keeping my .cshrc files under cvs control until 1993 so I can't easily check its evolution before then. I lost that CVS repo in a disk crash while not a practicing member of the church of the daily backup sometime in 1999, so I don't have a complete history between 1993 and 1999 (backup tapes have it up to sometime in 1998, but I didn't find those until after I started a new repo). : If memory serves (and it may not at this remove), /usr/local/bin : wasn't on my path until I started using VAXen, meaning there were few : or no packages installing in /usr/local on v6 v7 on the 11s. : : On V7 (the earliest software I have), vendor software installed itself : in /usr/[bin|lib], which is IMO worse than /usr/local. Agreed. The 4.2BSD and 4.3BSD VAXen that we had at New Mexico Tech in late 1985 didn't have a /opt, but did have a /usr/local which is where software installed itself. We were at a university, and I think we had local hacks to include /usr/local/bin and /usr/ucb/bin in the paths for these machines. As they were VAX 11/750s, we had no X software since this machine predated the availibility of Sun 3/50 workstations at New Mexico Tech, which didn't arrive until late 1986 and weren't online until early 1987. They didn't run X11 until late 1987 or early 1988 iirc. And then X11's installation dir wasn't well standardized. Some software installed in /usr/X11/bin and others installed in /usr/bin/X11. Gosling Emacs was installed in /usr/local/bin/emacs for sure. I don't have my historic Unix version CD handy, or I'd check the man pages from 4.xBSD to check, but version 1.1 of the hier(7) from 1994 says: /usr/ ... local/local executables, libraries, etc. ... but there also was a /usr/contrib for large packages contribtued to Berkeley by outside parties. /usr/contrib was, I think, invented for 4.4BSD, but maybe it was for 4.3BSD. Without the sccs trees handy, I have no way of knowing the exact details. Looking at NetBSD's hier from the same time frame (actually 1 year earlier in 1993) shows the same text. The page itself is dated 1991. NetBSD's /usr/pkg didn't get documented until 1998/04/02 according to the cvs log and that was something that they invented at the time because they didn't like FreeBSD's ports going into /usr/local. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Nate Williams [EMAIL PROTECTED] types: I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. Oh, I agree that installing things in /usr/local predates /opt by years. I'm curious as to what vendor provided software installed itself in /usr/local, though, as I've never seen any. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. On V7 (the earliest software I have), vendor software installed itself in /usr/[bin|lib], which is IMO worse than /usr/local. That sounds like you're agreeing with me, at least about v7. Nate Williams [EMAIL PROTECTED] types: Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( SysIII was not something I ever worked with. I went from v7 to BSD until, and stayed pretty much BSD until I started working with Solaris in the early/mid 90s. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. I few this as consciousness-raising. That's an ongoing process. My claims about "history" and "tradition" are attempts to refute Brandon's assertion that packages going into /usr/local has "years of tradition behind it." Mostly, it's about what *packages* are, not what /usr/local was used for. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 03:15:58PM -0700, Warner Losh wrote: but there also was a /usr/contrib for large packages contribtued to Berkeley by outside parties. BSDi's BSD/OS installs GNOME, KDE, editors, etc.. into /usr/contrib and leaves /usr/local for the user. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
"Daniel C. Sobral" wrote: Mike Meyer wrote: Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. I worked on smail as early as 1985; it installed in /usr/local way back then. I think the "/usr/local is for local extensions" is a SysV mindset. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Andrew Reilly [EMAIL PROTECTED] types:
On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
${PREFIX}/etc, and stored in perforce. The perforce database is on
/usr/local, and saved along with everything else.
In fact, *all* my system configuration files are stored in
perforce. In theory, I can restore a system configuration from
that. Since I haven't actually used it, I expect it to work as well as
setting LOCALBASE works.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
I dislike /opt as well. For two reasons. One is that it's not on /usr
meaning I have to either set aside another large FS for system
software, or tweak things to get it there. The other is that all the
packages have their copy of the hierarchy. If there were a hook to
install symlinks in a standard heirarchy under /opt, it wouldn't
bother me so much. But there isn't, so I have to figure out what needs
to be installed, do it by hand, and take some action to insure it gets
recreated if I need to do that.
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
Yup. I also keep the source for random software from the network in my
home directory. I don't keep the source for ports anywhere. That's
part of the basis for the claim that "installed over the network" and
"FreeBSD packages" are *not* identical, and losing the ability to
easily separate them is bad.
For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
Why don't you go ahead and turn it into a port, and submit that? I've
done that - even for locally written software. Being able to use the
ports mechanisms to maintain the installation of software is a win. I
also PR them, and every once in a while one of them gets committed
before the ports structure changes so much the port is outdated.
Whether I turn true third party software into a port or not, I put
network sources in an external source branch, and my build version in
a local branch so I can use source software management tools to deal
with upgrades from the vendor. I *never* do that with a port. I don't
manage that software - someone appointed by FreeBSD does. Again,
that's a reason for wanting the two kinds of software in different
hierarchies, and FreeBSD coopting the place where much of that
software expects to be installed being a pain.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
Making the default something other than /usr/local makes it more
likely that PREFIX/LOCALBASE will work. Also, as was pointed out
elsewhere in the thread, if ports go somewhere that nobody uses for
anything, a simple symlink will make it look like it's where ever you
want it, and you get the two things merged. If the default occupies
something
Re: Confusing error messages from shell image activation
I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. Oh, I agree that installing things in /usr/local predates /opt by years. I'm curious as to what vendor provided software installed itself in /usr/local, though, as I've never seen any. I know that as recent as 3=4 years ago, Purify installed itself by default in /usr/local, on SunOS and Solaris. Lucid did this as well, although things start getting pretty fuzzy going back that far. :) Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( SysIII was not something I ever worked with. I went from v7 to BSD until, and stayed pretty much BSD until I started working with Solaris in the early/mid 90s. I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. I few this as consciousness-raising. That's an ongoing process. My claims about "history" and "tradition" are attempts to refute Brandon's assertion that packages going into /usr/local has "years of tradition behind it." Mostly, it's about what *packages* are, not what /usr/local was used for. I disagree. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Nate Williams [EMAIL PROTECTED] types: I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early 90s, and don't remember anything being in /usr/local that I didn't drag of the net (or write myself) and install there, on either VAXen or MIPS boxes. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. I'd certainly be interested in that. Of course, as you yourself said, the argument about tradition is a sideline. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early 90s, and don't remember anything being in /usr/local that I didn't drag of the net (or write myself) and install there, on either VAXen or MIPS boxes. Hmm, trying to dig up memories of the software from that long ago. Software that run a piece of chemistry hardware (a electronic microscope?) sounds right, but I wouldn't bet my life on it. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. '/opt', '/usr/pkg', '/whatever-you-want-to-call-it'. You were the one who claimed that Solaris was the first 'vendor' to provide packages, and they used opt. Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. I'd certainly be interested in that. It'd be Purify. Of course, as you yourself said, the argument about tradition is a sideline. Yep. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. Not true. You can change the source to point to '/usr/mike-likes-it-here', and it *should* work. If it doesn't, then it's borken. :) Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The default setup for locally built ports can stay exactly as it is. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Fixing broken things is a good thing. Your argument about 'moving it from /usr/local to show how broken' is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". I don't think anyone is agreeing. Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. I don't see how building it for /usr/local or /usr/pkg by default changes things. If things are built for a default location, they'll be broken no matter where they go. The default setup for locally built ports can stay exactly as it is. I don't agree that we need to differentiate between 'pre-built' ports and 'locally built' ports. As a matter of fact, I think differentiating only confuses things. If the 'port' is broken w/regard to not using it's 'base', then it's broken, no matter where it's installed to. I think time would be better spent fixing this brokeness rather than arguing where the default should be. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[current] Re: Confusing error messages from shell image activation
"Brian" == Brian Dean [EMAIL PROTECTED] writes: Brian I'm really not exactly sure what you are complaining about. Brian For example, the last time I built Emacs for Solaris (several Brian years ago admittedly), by default it installed itself into Brian /usr/local. If you install Emacs onto FreeBSD, it goes into Brian /usr/local. The behaviour is the same. Are you proposing that Brian since FreeBSD provides a set of patches so that Emacs builds Brian cleanly, that it should therefore install it somewhere other Brian than /usr/local? I'm jumping into the middle of an argument that I havn't been reading, but I've had the very same argument with a number of people. It's fairly predictable. For foreign or not-so-foreign packages and software, I've seen /usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I worked at was even pedantic that /usr/contrib was for externally generated software and /usr/local was for software written and/or maintained locally. I've also worked in environments where different directory structures implied the level that the IS guys intended to support the software. Arguing about any of that in an OSS project is silly. However, I believe that /usr/ports should install all it's software in one place and that place _shouldn't_ be /usr/local. Reasoning: - having it install in /usr/X11R6 and /usr/local is confusing. Having random software put itself in either /usr/X11R6 or /usr/local is more confusing. Having ports even migrate from /usr/local to /usr/X11R6 is even more confusing. - having all ports under one tree allows you to share a tree of ports without sharing a tree of /usr. - would allow package management (eventually) to say that every file under /blah is accounted for by the package database. - (and the reason it shouldn't be /usr/local) ... many packages on the net install in /usr/local by default ... so I can see the lazyness in just accepting that. However, /usr/local is a useful place for an administrator to put things that are not part of the ports collection that he has hand compiled onto the machine. In many cases an inordinate amount of work would be required to change a piece of software that was only to be installed on one machine. It also forces all ports to be PREFIX enabled ... which is useful. Now... I think it would be useful to have arguments about more complex package software that allowed /usr/pkg/foo to hold all of foo and linking /usr/pkg/bin/foo to /usr/pkg/foo/bin/foo ... 'n stuff like that. Complete separation and versioning are desireable things. I suppose if everything was dead accurate (which it's not) you could account for every file in the namespace ... which would be way-cool ... but separating packages might be more sensible. ... but /usr/pkg supplanting /usr/local is one of the things that I like about NetBSD. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Andrew Reilly [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The course of this conversation made me realize that the reasons I subscribed to FreeBSD in the first place no longer hold - except for financial contributions to the project, that is. The install disk and and live file system are nice to have, but not crucial. The real reason was having all those precompiled packages and/or distfiles around. But the distfiles vanished as of 4.0, and the ability to use the packages vanished when I set LOCALBASE to /usr/opt and rebuilt all my installed ports. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) The office52 port is quit happy installing anywhere - I've got it at /usr/opt on my system. The WordPerfect and NetScape ports are also PREFIX clen. On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
In message [EMAIL PROTECTED] Nate Williams writes: : I know that as recent as 3=4 years ago, Purify installed itself by : default in /usr/local, on SunOS and Solaris. Lucid did this as well, : although things start getting pretty fuzzy going back that far. :) purify and the binary distributions of xemacs installed themselves into /usr/local on Solaris in the 1992-1996 time frame. As did *ALL* of the software binaries we downloaded from the net. Framemaker installed in /usr/local as well in the SunOS 3.5/4.0 time frame. Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame. : My claims about "history" and "tradition" are attempts to refute : Brandon's assertion that packages going into /usr/local has "years of : tradition behind it." Mostly, it's about what *packages* are, not what : /usr/local was used for. : : I disagree. I do too. : Probably the same time-frame for SunOS, although I didn't have : experience with it until the early 90's. However, if necessary, I can : try and dig out installation docs for some software which ask to have : the stuff unpacked in /usr/local. I still have some backup tapes of our main server from the 1992 time frame that shows software packages from ISVs installed into /usr/local/bin. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
In message [EMAIL PROTECTED] Nate Williams writes: : Probably the same time-frame for SunOS, although I didn't have : experience with it until the early 90's. However, if necessary, I can : try and dig out installation docs for some software which ask to have : the stuff unpacked in /usr/local. : : I'd certainly be interested in that. : : It'd be Purify. Try also Interleaf, FrameMaker, the elan license manager, eroff, lucent emacs binaries for the net, TeX binaries from the net, gosling emacs, and I think informix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
In message [EMAIL PROTECTED] Mike Meyer writes: : Corrections first: The only place where FreeBSD fails to follow FHS : (in my quick perusal of it) is in putting packages in /usr/local : instead of /opt. You can't blame that part of FHS on Linux - I have as : yet to see a Linux distro or package do it that way. No, this bit : comes from commercial vendors, where it's also steeped in years of : tradition. Not as many as you might think. /usr/local predates /opt by several years. : Rant second: FreeBSD *violates* years of traditions with it's : treatment of /usr/local. /usr/local is for *local* things, not add-on : software packages! Coopting /usr/local for non-local software creates : needless complexity and confusion, which of course leads to needless : pain. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, Mike Meyer wrote: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, Brandon D. Valentine wrote: On Sat, 9 Dec 2000, Mike Meyer wrote: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. And before somebody else jumps in, yes I fat-fingered the numpad. That's hier(7), not 5. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Brandon D. Valentine [EMAIL PROTECTED] types: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. Corrections first: The only place where FreeBSD fails to follow FHS (in my quick perusal of it) is in putting packages in /usr/local instead of /opt. You can't blame that part of FHS on Linux - I have as yet to see a Linux distro or package do it that way. No, this bit comes from commercial vendors, where it's also steeped in years of tradition. Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. All of which has nothing to do with the question of whether we want to continue giving error messages that are wrong, or commit this patch and provide ones that are actually informative. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, Dec 09, 2000 at 08:21:28PM +0100, [EMAIL PROTECTED] wrote: Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. Okay, let me rephrase: It would be nice if FreeBSD *by default* stored the packages/ports under /usr/pkg, like NetBSD (and the corresponding sources under /usr/pkgsrc). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, Dec 09, 2000 at 08:28:07PM +0100, [EMAIL PROTECTED] wrote: like NetBSD (and the corresponding sources under /usr/pkgsrc). Please stick to reasonable ideas. To move the CVS repo from ports/ to pkgsrc/ would be totally unreasonable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Not likely to happen - people have an investment in the current scheme and it would certainly mess with their heads if one day FreeBSD suddenly started doing something entirely different than what it's been doing for the last 7 years. For those who really want to track the NetBSD way of doing things, it can be set according to their own tastes. - Jordan Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. Okay, let me rephrase: It would be nice if FreeBSD *by default* stored the packages/ports under /usr/pkg, like NetBSD (and the corresponding sources under /usr/pkgsrc). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000 12:32:01 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS I have never heard of ``FHS''. What is its ANSI, FIPS, IEEE, IEC, or ISO number? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, David O'Brien wrote: On Sat, Dec 09, 2000 at 08:28:07PM +0100, [EMAIL PROTECTED] wrote: like NetBSD (and the corresponding sources under /usr/pkgsrc). Please stick to reasonable ideas. To move the CVS repo from ports/ to pkgsrc/ would be totally unreasonable. I've always thought /usr/pkg/src a logical place to put it. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Thu, 23 Nov 2000 23:39:07 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: Um - compliance with what, exactly? IEEE Std.1003.1-1990 et seq. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
* Mike Meyer [EMAIL PROTECTED] [001122 22:41] wrote: Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. This patch may break compliance, ENOEXEC is the proper error code, the shell should try to be a bit smarter about explaining why ENOEXEC was returned. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Alfred Perlstein [EMAIL PROTECTED] types: * Mike Meyer [EMAIL PROTECTED] [001122 22:41] wrote: Could I get some feedback on URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 ? It's just a one-line kernel patch with some attendant updates in the kernel and libc, but it makes dealing with broken #! scripts *much* saner, and no one has even seen fit to comment on it yet :-(. Thank you for taking time to look at it. This patch may break compliance, ENOEXEC is the proper error code, Um - compliance with what, exactly? I know it breaks compliance with Unix standards for user friendliness, but that was the point. I also agree that ENOEXEC is the best currently existing error code - but for this it pretty much sucks. Exec returns other codes providing more informative error messages; adding one more shouldn't be a problem. the shell should try to be a bit smarter about explaining why ENOEXEC was returned. Um - not "the" shell; all of them. Given that the authors of some of them are worried about portability, doing so portably is probably important as well. That's why I decided it belonged in the kernel. Doing this means that all shells get the benefit of it without a source change, and the only change other than better error messages was if there is an executable with the same name behind a broken script in the path - and I *couldn't* convince myself that was a problem! mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
