Brooks Davis wrote:
> I'm fairly sure that some of the software distributed by SGI on their
> unsupported free software media does this.
Incorrect. SGI IRIX uses /usr/freeware and has for at least
all of 6.X. I think 5.3 may have also used that path.
To Unsubscribe: send mail to [EMAIL PROTEC
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=$(exp
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
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 design
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
> b
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
>betw
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 r
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
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 wha
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 /u
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
> 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 ar
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
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
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 live
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 unpacke
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 distribution
In message <[EMAIL PROTECTED]> "Andrew Reilly" writes:
: 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...)
Solaris 2.x introduced it, but packages that ran on bo
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
> "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 Emac
> > 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
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 FreeB
> > 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) an
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
> > > 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 itse
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
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 co
"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 con
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 PROTECTE
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
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 soft
"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
> 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.
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 th
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 fil
On Sun, Dec 10, 2000 at 02:04:36AM -0700, Warner Losh wrote:
> Ummm, software packages have been make installing into /usr/local
> since at least 1985 when I started building them. no coopting has
> been done.
Yes, "software packages", no "FreeBSD Ports Collection Packages" as they
didn't exist
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.
> Th
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
> >
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
>unsupport
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
--
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 instal
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 *ex
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
ins
Garrett Wollman <[EMAIL PROTECTED]> types:
> < 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
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 complex
[Please watch your carbon copies!]
< 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 Fre
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 needles
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
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
< 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 t
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 thi
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
On Sat, Dec 09, 2000 at 08:28:07PM +0100, [EMAIL PROTECTED] wrote:
> 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).
Well, that is one tradition that we'll be breaking if o
> > 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
s
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-
> 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
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 stan
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
>s
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
Garrett Wollman <[EMAIL PROTECTED]> types:
> < said:
> > Um - compliance with what, exactly?
> IEEE Std.1003.1-1990 et seq.
Since no one has bothered to close this PR with a note that this
noncompliance is unacceptable, I'm assuming that no one considers it
so. Further, it's not clear that FreeBS
< 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
Alfred Perlstein <[EMAIL PROTECTED]> types:
> * Mike Meyer <[EMAIL PROTECTED]> [001122 22:41] wrote:
> > Could I get some feedback on > 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 de
* Mike Meyer <[EMAIL PROTECTED]> [001122 22:41] wrote:
> Could I get some feedback on 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
> on
63 matches
Mail list logo
