Linux App Installs
to a '/apps' Directory
for example,
$HOME/apps ... or /apps
Linux App Installsto a '/apps' Directory
for example,
|
|
< Go to the Table of Contents, below. >
(skip the Introduction)
|
INTRODUCTION : This page is motivated by several situations :
In relation to the 2nd item above (files scattered) : I have to agree with a writer in a recent Linux Format Magazine (Nov 2010) --- see quotes below. Application developers should consolidate almost all of their application's files into one directory --- instead of scattering them throughout various Linux directories like '/usr/bin' and '/usr/share' and '/etc' (and '/usr/local' and '/opt') --- and sometimes even '/var'. Here is what Mike Saunders of Linux Format Magazine wrote in the Nov 2010 issue, in an article entitled '24 Things We'd Change About Linux' : "The current Unix-style filesystem layout is an archaic mess. It's silly that, when you install a program,it's exploded into loads of different directories all over your filesystem. Apps should be standalone, like in ... Mac OS X and many other desktop OSes. Gobo Linux has the right idea." I couldn't agree more. It is ridiculous to put the main binary executable in '/usr/bin', the documentation in '/usr/share/doc', various dynamic executables (especially ones unique to the application) in '/usr/lib' or '/etc/lib' or '/lib', etc. etc. .... And, to make matters worse, some app developers use '/opt' or '/usr/local' instead of '/usr'.
On 'shared libraries': It may be necessary, in many cases, to continue to use a 'central' '/lib' directory for those 'dynamic shared objects' --- but, even then, it would probably be good to have just '/lib' --- not '/usr/lib' in addition. Furthermore, it is not infrequently the case that one application needs a different version of some library, different from the version that other applications that are installed on the computer need. Unfortunately, for various reasons, the shared library filenames often do not include a version number --- or a sufficiently qualified version number (a sub-version number). So installing multiple versions of a shared library under a central '/lib' library can be problematic. For cases like that, it may actually be better to have a 'lib' directory in the application directory --- $HOME/apps/superapp/lib in the example mentioned above --- rather than having to try to install a different version of a library under /lib and then have to use a wrapper script, with the LD_LIBRARY_PATH variable, to point out the location of the desired version of the 'shared library'. In some cases, it is better to use a little extra disk space that MAY duplicate the libraries contained elsewhere, rather than to have really frustrating, time-consuming problems trying to get an application to run. Mike Saunders augmented his quote, above, with some specifics on the Gnome desktop system : "Do we really need hidden directories called '.gnome', '.gnome2', and '.gnome2_private'? At least KDE has the courtesy to put all its files in one place --- and has done for a long time." I think he is referring to the hidden directory '$HOME/.kde' where most KDE user-preferences files reside. In fact, ... When people have problems with Gnome desktop icons disappearing or Nautilus mal-functioning, in forum threads you usually see advice on removing (or renaming) the several Gnome hidden directories in your home directory, because a file in those directories has probably been corrupted. The three directories often mentioned are :
However, there are another couple of hidden-home-directories that can house the culprit ( I have found the hard way) --- namely:
It sure would be helpful if all Gnome files in a user's home directory were located under a single sub-directory of the home directory --- like $HOME/.gnome2 or $HOME/.gnome3 --- or simply $HOME/.gnome. Why this page : I have started this page to describe how I have installed some 'applications of interest' under an 'apps' directory --- usually $HOME/apps/<appname>. A 'table of contents', below, offers links to 'application-sections' further down this page. Those 'application-sections' describe how a particular application was installed under an 'apps' directory like $HOME/apps/ --- rather than using a typical Linux package-manager install, which scatters the application files over directories such as
You can use the 'table of contents' --- or simply scroll down this page to find information of interest. OR, use the 'Find Text' option of your web browser to look for keywords of interest --- such as 'text editor' or 'browser' or '3d' or 'script' or whatever. |
|
Table of Contents : (links to '/apps install' info below) '/apps-installation' of
|
|
Notes on '/apps-installation' of SciTE : Here is how I installed a version of the SciTE text editor under my $HOME/apps directory on a Linux computer.
In case gscite 2.27 ever stops working with error messages indicating a '.so' (shared object, dynamic executable) is not found, one might be able to get it going again by putting the proper version of the '.so' file into the '$HOME/apps/gscite_2.27/' directory, say, and using the LD_LIBRARY_PATH variable in a 'wrapper' script to get gscite going again. For reference, here is an 'ldd' (print shared library dependencies) list showing the dynamically-called executables of the gscite 2.27 executable. Note that there are about 49 'dependencies' in the gscite 2.27 executable --- a considerable opportunity for things to get out of whack as these shared libraries go through upgrades. This is a major reason why major, relatively-reliable Linux distros release periodically based on a set of shared libraries and applications that have undergone quite a bit of developer effort to make sure the applications and shared libraries are compatible with each other. That is why it would take an expert (and patient) Linux user to keep a 'rolling release' Linux distro running. As shared libraries are upgraded to a next release, a sh*tload of applications could suddenly be failing with '.so not found' messages. I have better things to do with my time. I am leery about the amount of time I would be wasting if I were to use a 'rolling release' distro on my main machine(s). I am happy to be a grateful beneficiary of the time spent by 'distro preparers and updaters' to keep a release functioning. Scite Global Properties file (2011sep25 update) After doing this type of install of 'gscite', into $HOME/apps/gscite_2.27, on one of my netbooks, I found that the status line at the bottom of the 'gscite' GUI was not showing the 'li=M co=N' (line and column) indicator like I was seeing in my desktop install. I traced the issue down to needing the Scite 'Global Properties' file installed in a directory in which the 'gscite' program will find it. Filename: 'SciTEGlobal.properties' By using the 'strings' command on the 'SciTE' executable, I generated a file containing the human-readable strings in the text editor executable. I scanned that file for occurrences of '/usr'. You can see that the directory '/usr/share/scite' is referenced --- right after what looks like an environment variable called 'SciTE_HOME'. If I were going to use the environment variable, I probably could have used a command like export SciTE_HOME="$HOME/apps/gscite_2.27" to let the 'SciTE' executable know where to look for the 'SciTEGlobal.properties' file. But then I would have had to write a 'wrapper' script for the 'SciTE' executable (something I did not want to do, since I was trying to keep the install almost untouched by human hands) --- or put the command in my '.bashrc' or '.bash_aliases' file, to be executed whenever I opened a terminal (ugh) --- i.e. even if I were not going to use 'gscite'. Since I figured that the 'SciTE' executable might 'be more comfortable' looking for what it needs in the '/usr/share/scite' directory, I looked for a 'scite' subdirectory in '/usr/share'. It did not exist, so here are the steps (commands) I performed to make the 'SciTEGlobal.properties' file available to the executable.
After I did that, the 'li=M co=N' (line and column) indicator showed up at the bottom of the 'gscite' text editor window. I am not sure which of the many parameter-setting statements in the 'SciTEGlobal.properties' file caused that to happen, but here is an image of the 'SciTEGlobal.properties' file for SciTE 2.27, so you can have a look for yourself. Scite User Properties file (2011sep25 update) As delivered, SciTE defaults to a 'variable-width' font for the text EVERY TIME the editor starts up. I got tired of repeatedly using the 'Options > Use Monospaced Font' menu pop-down to change to a 'fixed-width' font. So I established a '.SciTEUser.properties' file in my home directory to set some user preferences. Here is an image of my '.SciTEUser.properties' file as of 2011sep19. You can see the 'font.' statements that I used to make sure most of the font variables were set to a 'fixed-width' font. In addition, you can see some other tailoring (variable assignment statements) that I added. Some of these choices are ones documented by other SciTE users. I found those settings by doing a Google search on terms like 'scite user properties font' or 'scite user properties tab indent'. Here are links to a few of the helpful pages I found on setting SciTE user preferences:
I am a pretty happy 'gscite' user now. It sure beats 'gedit' --- especially in the area of behaving properly when doing quick 'left-click-swipe-capture/right-click-copy' operations with the mouse. I documented, near the bottom of my Ubuntu Installs page, how deficient 'gedit' is in this highly desirable operation. Combining the 'Global' and 'User' Properties files (2013mar20 update) The next time I install 'gscite' on one of my computers (all of which use Linux), if I feel I have the time to spare, I will look into consolidating the statements from the 'Scite Global Properties' file and the 'Scite User Properties' file into one 'Scite User Properties' file. Then I could use just the 'Scite User Properties' file without having to deal with a 'Scite Global Properties' file. And I may try to whittle down the control statements in that combined 'Scite User Properties' file to a near-minimal set of control statements that provide the editing features that I prefer. |
|
Notes on '/apps-installation' of FE subsystems : The 'xpg' and 'feAppMenus' subsystems of the FE (Freedom Environment) system were designed to be installed under $HOME/apps. For a description of how those subsystems can be installed in $HOME/apps, see the 'Downloads' pages for 'xpg' and 'feAppMenus' at the freedomenv.com web site. Briefly, the install is via downloading a 'self-extracting script' into a downloads directory --- typically $HOME/Downloads. Then it is basically 3 steps to install each subsystem under $HOME/apps :
Voila. The files are all under $HOME/apps --- except for a couple of files under $HOME/.freedomenv. There are a few 'soft-links' under $HOME/apps/bin --- to provide for startup of a main executable without having a release ID in the startup file name (the link file name). Note that nothing is under root-owned directories like /usr/bin, /usr/share, /usr/lib, or /etc. In fact, you do not have to 'switch to root' and use the root password to install the FE subsystems. You install them using your own userid and all the files are owned by the user, not by 'root'. |
|
Notes on '/apps-installation' of SEAMONKEY : Here is how I installed a version of the Seamonkey web browser under my $HOME/apps directory on a Linux computer. In mid-2010, the Seamonkey web browser was not available in either the Ubuntu Software Center nor via the Synaptic package manager, so I went to the seamonkey web site and downloaded a version for Linux and installed it under $HOME/apps. For example, in July 2011, you could go to the Downloads page of the seamonkey-project.org site, and download a Seamonkey 2.2 'Linux GTK2' install file (a '.tar.bz2' file). I downloaded it into my $HOME/DOWNLOADS directory. Then, in the Nautilus file manager, I right-clicked on the '.tar.bz2' file and chose to open the file in the 'Archive Manager' (which is called 'File Roller' by its developers). Then I chose to extract the '.tar.bz2' file in $HOME/apps. Nautilus gave me the opportunity to make a sub-directory there. I made the subdirectory 'seamonkey2-2'. I clicked on a button to do the Extract, and the files were extracted into '$HOME/apps/seamonkey2-2' in a few seconds. DONE. Here is a list of the Seamonkey 2.0.11 files under $HOME/apps. Note that rather than scattering shared object (.so) files under subdirectories of /usr/lib or /lib, the Seamonkey '.so' files are kept together with the other Seamonkey files --- files such as the 'seamonkey' startup script and the 'seamonkey-bin' binary executable file. Also note that it would be a pretty easy matter to remove the Seamonkey 2.2 installation. Almost all the files would be removed by simply deleting the directory $HOME/apps/seamonkey2-2. Like with the FE (Freedom Environment) files, all the Seamonkey files are owned by the user, not by 'root' --- and you do not have to use the 'root' password (or 'su' or 'sudo') to install the Seamonkey files. |
|
Notes on '/apps-installation' of 3D converters : ('ivcon' and 'ivread') I have described how I compiled a couple of 3D converter programs ('ivcon' and 'ivread', of John Burkhardt) on this 3D converters - notes and code page. After compiling them, I simply put the binaries under directories '$HOME/apps/ivcon_2004' and '$HOME/apps/ivread_2002'. I can make 'wrapper' scripts for the two binaries and put those scripts in a '$HOME/.gnome2/nautilus-scripts' sub-directory. Then I can easily apply either conversion utility to a 3D file by right-clicking on the file when in the Nautilus file manager. |
|
Notes on '/apps-installation' of Blender : (added 2013 Mar 20) Around the end of 2012 and beginning of 2013, I was developing a Tcl-Tk script to read and display 3D model files (ASCII files such as Wavefront OBJ files as well as OFF and PLY and STL files). I found it would be helpful to use some of the conversion facilities of Blender to read in binary model files (such as '.blend' files or '.3ds' files) and write out ASCII OBJ files. So I wanted to install a recent release of Blender on my desktop development machine that is/was running a several-year-old version of Ubuntu (9.10 = the 2009 Oct version = 'Karmic Koala' --- the best-ever version of Ubuntu in my opinion --- Ubuntu went down-hill after that release). I went to the blender.org web site and downloaded the most recent version --- 2.66. But when I installed it (in $HOME/apps/blender2-66) and tried to run the 'blender' executable, I received an error message that indicated that I did not have a compatible version of 'libglew'. But Blender provides a directory of downloads for past releases, and I installed Blender 2.65 in $HOME/apps/blender2-65 --- using a version with the name 'glibc27' in the install file name, instead of 'glibc211'. In a little more detail: To install Blender 2.65, I made a 'blender2-65' directory of my '$HOME/apps' directory. Then I simply downloaded the 'blender-2.65-linux-glibc27-i686.tar.bz2' file into that directory and de-archived it with the 'Archive Manager' of the Nautilus file manager, a.k.a. 'File Roller'. Here is a link to the list of files in the Blender 2.65 installation --- Blender 2.65 recursive list of directories and files. For reference, here is an 'ldd' list (of shared library dependencies) showing the dynamically-called libraries of executables corresponding to the Blender 2.65 executable. This list shows the release levels of the dynamically called libraries that are used by Blender 2.65. Note that the list indicates that the libraries will be looked for in the 'central' directories '/usr/lib' or '/lib'. I considered finding copies of the dynamic libraries that were needed to run the newer version of Blender. Conceivably, I could put copies of those libraries in the 'lib' subdirectory of the Blender installation (under $HOME/apps/blender2-66) and write a 'wrapper' script for the 2.66 'blender' executable that provided the location of the newer libraries, in a LD_LIBRARY_PATH variable. But repeatedly running Blender after resolving each error message, to find the next library incompatibility, may have been a long and tedious process. So I chose to simply install release 2.65 instead of release 2.66. To startup Blender 2.65 via an icon on my Gnome2 desktop, I right-clicked the desktop and chose the 'Create Launcher...' option. In the popup dialog window that appeared, I entered 'blender2.65' for the icon name and used the 'Browse...' button to navigate to the executable file /home/<userid>/apps/blender2-65/blender-2.65-linux-glibc27-i686/blender and select that file as the 'Command'. Voila. Done. Note that I never had to switch to 'root' to do the installation, and I did not put any files in a root-owned directory such as '/usr' (although I could change the ownership of the blender executable to 'root' if I feel that I need to). The complete installation is in my home directory, which I back up regularly. Hence all the applications in the '$HOME/apps' directory --- including Blender 2.65 --- will be available when I upgrade to a new version of Linux --- whether (1) I do a 'distro' install and not overlay the home directory, or (2) do a 'distro' install that makes a 'fresh' home directory and then drag the 'apps' directory from my backup to the new home directory. And if this version of Blender is not compatible with libraries in the new version of Linux, then I can simply repeat the Blender installation, using a more recent version of Blender, as outlined above. |
|
Bottom of this
To return to a previously visited web page location, click on
the Back button of your web browser, a sufficient number of times.
OR, use the History-list option of your web browser.
< Go to the Table of Contents, above. >
Page was created 2011 Jul 03.
|