Steve Lamb <[EMAIL PROTECTED]> wrote:
>> I dunno about you, but that is the very definition of "spread out"
>> especially when you consider that {package} in /opt can be quite a
>> few. I'm disgusted with my path on my Solaris box at work. I
>> needed to add /opt/gnu/gimp/bin, /opt/gnu/gcc/bin and /opt/netscape
>> to my path just to get things to run which should have been, to me,
>> in what is in my path in the first place.
Steve Greenland <[EMAIL PROTECTED]> writes:
> As another sometimes Solaris and HP user, hear hear. If the only way
> you have to manage software packages is 'make install' or 'tar -x'
> and 'rmdir', then "/opt" seems like a good idea. Given a decent
> package management system (like dpkg or rpm), then /opt is an
> unnecessary administrative-nightmare kludge. I think my path was up
> to 10 or 12 *lines*.
I would tend to share some of the blame for PATH length problems on
your local system administrator.
But anyway, since when does Linux do things exactly the same way as
Solaris and HP? We may borrow ideas from other Unix systems, but we
can improve on them. Please read the FHS section on /opt,
specifically /opt/bin.
If the length of the PATH is a serious problem, we could potentially
to make /opt/bin front-ends a requirement. However, you then have to
solve (or at least ignore) the problem of potential namespace
conflicts. Add-on applications tend to be very cavalier about
including binaries named things like "setup", "install", and "start".a
- Dan
