/opt directory replacement

I can do this, but I prefer to follow OS guidelines, and place my program to the place where other programs are installed.
 
Everything that isn't part of the base OS (ports) is installed with the /usr/local/ prefix.
 
if you want to use use custom builds, then I suggest to install in /usr/local/opt
and add /usr/local/opt/bin to your PATH environment variable
This way you won't mess ports with custom installed software, and it's easy to fix if anything goes wrong

As SirDice said I'd set PREFIX=/usr/local/opt for custom software, that aren't part of ports
 
another option could be to install in somewhere in home directory if you don't want others to have access to these apps
 
phoenix said:
hier(7)
Click to expand...

As is noted at the bottom of the document...

Code: 
NOTES
     This manual page documents the default FreeBSD file system layout, but
     the actual hierarchy on a given system is defined at the system adminis-
     trator's discretion.  A well-maintained installation will include a cus-
     tomized version of this document.

So it's up to you where to put things, but as a basic rule of thumb, everything 3rd party goes into /usr/local (including /opt on Linux, which is just another whacky idiom for /usr/local)
 
killasmurf86 said:
if you want to use use custom builds, then I suggest to install in /usr/local/opt
and add /usr/local/opt/bin to your PATH environment variable
This way you won't mess ports with custom installed software, and it's easy to fix if anything goes wrong

As SirDice said I'd set PREFIX=/usr/local/opt for custom software, that aren't part of ports
Click to expand...

Bad advice. What do you propose to do with libs, configfiles, rcscripts, manpages, docs...?

(BTW I think you misquoted SirDice)
 
jalla said:
Bad advice. What do you propose to do with libs, configfiles, rcscripts, manpages, docs...?
Click to expand...
What about self-contained binaries? Isn't that how PC-BSD packages their applications in the PBI? While self-contained binaries would use more space they could, without causing problems with a working system, make it easier to:
  1. build, test, and use a newer version of an application that is in ports (i.e. graphics/gimp v2.8.x instead of v2.6.x)
  2. create your own or build a third party application, even if it uses libraries that are in ports.
  3. modify an application that is in ports with changes you intend to send back to the maintainer so it can get incorporated into a future release. For example; modify audio/moc or audio/cmus to use audio/faad2 for playing AAC/M4A files instead of using multimedia/ffmpeg.
  4. "freeze" an application that is in ports but is in danger of disappearing (i.e. it is no longer being maintained, it uses old libraries that are being removed from ports, etc.)
 
jalla said:
Bad advice. What do you propose to do with libs, configfiles, rcscripts, manpages, docs...?
Click to expand...
Then what exactly do you propose for us? Not very helpful on the forum to shoot down advice without providing a valid alternative. There should be an agreed upon directory for random software.
 
You must log in or register to reply here.
Back
Top