Tom Allison wrote: > Colin Watson wrote: > >Tom Allison wrote: > >>FHS says that this directory is for "binaries not needed in single user > >>mode". > >>But then I went over and looked at the /opt which also seemed rather > >>reasonable as a place to put things. Those are definitely six of one and a half-dozen of the other types of locations. Either *could* world. A judgement call was made and one or the other picked. Different distributions or commercial vendors made that choice differently. Commercial vendors tend to like to put optional components into /opt. But I have also seen then put non-optional software there too. Nobody is perfect and I think those have been bugs but so it goes. > Wouldn't it be possible to utilize /opt for big packages (open office, > mozilla, KDE, Gnome, Java) and still leave /opt for system administrators? Using /opt means one of a) adjusting PATH to include the /opt/pkg/bin dirctory or b) putting symlinks to /opt/bin and having /opt/bin always added to path or c) putting symlinks into /usr/bin pointing to there. There is no easy way to deal with PATH and putting packages into /opt. HP-UX tries to do option a) and I have quite a bit of experience with it and there are problems doing it that way. Option a) is bad because it means you need to reset your PATH after doing software package installation or removal. Option b) creates more complexity and has yet to be widely implemented. Option c) is basically the same as putting it in /usr/bin. Seems the simplest solution is just to put it in /usr/bin and handle all of the issues by using the system package manager. > I kind of like the idea of putting what you need for the basics in /usr and > the cool applications in /opt and spread it around a little bit. The FHS can't really say not to put things in /opt because that would cut out many of the commercial vendors. So they allow it and both the system and the admin can do what they want in /opt. That leaves two choice points. The system and the admin. Either could use it. You as the admin are free to install software in /opt. There has been some discussion that putting non-free software, which definitely is not part of Debian, there by the local admin might make a lot of sense. It would stand out that it is an add-on to the system and not part of Debian and that bug reports should not go to Debian for that software either. This looks to overlap with /usr/local. You as the local admin are free to install software there too. So why have two? /opt does have a use. /usr/local needs to be backed up but /opt does not need to be backed up on my site. I install local non-free software to /opt using the package manager which obviously I can reinstall again if I needed to. But /usr/local might have non-packaged, hand tweaked files. That needs to be backed up. But on my site /opt does not need to be backed up. It only contains packaged non-free software which can be installed again. No need to put that on the backup. Which makes a nice use model that is easy to differentiate for everyone. > I guess there's really no valid reason for going one way or the other but > that it's more important to have an agreed to schema when setting up files. Agreed. Debian Policy is the preexisting agreement in Debian for where things go. But there is also a lot of flexibility there too. You can make local policy decisions such as I have done and still fit seamlessly into the grander scheme of things. Bob
Attachment:
pgpzXPXUHKYql.pgp
Description: PGP signature