Common Install Standard
Hi all. Below is a submission for standard that I'm working on. I'd appreciate thoughts, comments, and ideas. Recently, I have been working over strategies for Linux on the desktop. In particular, I've been comparing usability of system administration tasks to Windows 2K/XP and Mac OS X, the main contenders on the desktop. System administration tasks are done by almost everybody who owns a computer. It's not only things like applying security patch's, but includes mundane things like cleaning out old files, changing thedial-up number for your ISP, and installing and removing software. The last point is a bit of contention under Linux. Sure, apt-get, urmpi, and the like make it easy to get and install the latest open source software from your favourite vendor, but they don't cover 'other'software. Third party, and closed source software is somewhat more difficult. Third party applications are often found on CDs, and quite often the vendor may not be around any more. While there are many arguments for and against closed source software, the fact is that it exists, and it needs to be installed, maintained, and eventually, removed. A common example of popular third party applications are games. Currently, every vendor has their own method of handling the installation and (optionally) removal of software. This is often handled by scripts, Make files, or an GUI application stored somewhere on the file system, perhaps on the original CD. This is confusing for the end user, and to be brutally honest, it's a mess. While it is possible to statically compile libraries, it's not exactly reasonable to have binary files with every single piece of information required to run a program. Things like icons, sound, data, andconfiguration files all often need to be accessible to the user and other programs. One possibility, that I put forward here, is for a simple install and uninstall system, based around symlinks, and a common applications directory. The application, to all outward appearances in most common file browsers, would appear as a file, but it's really a directory. Let us assume the application is called 'Foo'. Foo consists of binary files, supporting libraries, icons, configuration files usually found in /etc/, and so on. We can express most of these in terms of where they normally fit in the unix file system. A few, mainly icons, and programsshortcuts, vary from environment to environment. The 'Applications' folder is accessible from the users Control panel as a special directory, allowing write access with sudo and the rootpassword. The folder itself would most likely sit in somewhere like /usr/local/Applications/. Thus, our application 'Foo', would be in /usr/local/Applications/Foo/. It's file structure would look something like this: /usr/local/Applications/Foo/ /usr/local/Applications/Foo/icon.svg /usr/local/Applications/Foo/description.txt /usr/local/Applications/Foo/main -> ./tree/usr/local/bin/foo /usr/local/Applications/Foo/tree/usr/bin/foo /usr/local/Applications/Foo/tree/usr/lib/foo/libfoo.so /usr/local/Applications/Foo/install/etc/foo/foo.conf /usr/local/Applications/Foo/home/.foo/ To install, symlinks from are made from /usr/bin/foo and /usr/lib/foo/ and /usr/local/Applications/Foo/tree/usr/lib/foo/ to/usr/local/Applications/Foo/tree/usr/bin/foo, and to /usr/local/Applications/Foo/tree/usr/lib/foo/. A copy of /usr/local/Applications/Foo/install/etc/foo/foo.conf is made to /etc/, so that changes made to the configuration do not affect the original files of the program. At the most basic level, Foo/ needs to be copied from it's original source to /usr/local/Applications/ and a script run to copy files in Foo/install/ and make symlinks of the files in Foo/tree/. However, this allows for much greater usability. The file Foo/icon.svg can replace the standard folder icon, and Foo/description.txt can contain multiple language descriptions of the program, to be read by any program used to handle the installation and removal of applications. On moreuser-friendly systems, double clicking on the icon for the program on a CD would prompt the user if they wish to install the program. Attempting to delete the 'program' from the Applications directory would prompt the user if they wish to 'uninstall'. The computer would then remove the symlinks and any configuration files. It also allows the program to ask if the user wishes to remove the system configuration files, originally copied from the the Foo/install/ directory, and user configuration files, originally copied from the Foo/home/ directory. Other benefits of this method come to mind. Source installed packages, for example, Mplayer, instead of being installed directly into the file system, is instead copied into /usr/local/Applications/mplayer/, and installed in the above manner. Mplayer can then be copied easily to other systems, and removed easily. It is also fairly easy to install such applications in systems that do not support it 'natively'. Although a simple shell script is all that is required to 'install' the programs, files can easily be symlinked and copied by hand if need be. I will emphasise again that this system is not meant to replace things link apt-get and rpm, but sit alongside them, and provide a common simple platform independent way of installing third party software.
I like where you are going, and I promise to read a lot deeper than what I have so far. Ironically we did something similar with CL 2.1 and 2.3 with the /opt directory. in it we put a lot of the files that a user would normally have in the /home directory (since we didn't know what they would call it), and in many cases it was left there for them to use, without needing to add it to the /home/??? directory. which was great until they install a package from somewhere else, and ended up with 2 directories, the old stuff cluttering the disk. Such a structure approach, if followed, would make up for the lack of a registry, but I wonder if the installer should also leave an audit trail somewhere that tells you where the file was placed, so that foo's directories can be located when required. ( a registry, without the nightmare of a registry) On Thursday, August 14, 2003, at 06:13 PM, <edward(a)murrell.co.nz> wrote:
Hi all. Below is a submission for standard that I'm working on. I'd appreciate thoughts, comments, and ideas. Recently, I have been working over strategies for Linux on the desktop. In particular, I've been comparing usability of system administration tasks to Windows 2K/XP and Mac OS X, the main contenders on the desktop. System administration tasks are done by almost everybody who owns a computer. It's not only things like applying security patch's, but includes mundane things like cleaning out old files, changing thedial-up number for your ISP, and installing and removing software.
The last point is a bit of contention under Linux. Sure, apt-get, urmpi, and the like make it easy to get and install the latest open source software from your favourite vendor, but they don't cover 'other'software. Third party, and closed source software is somewhat more difficult.
Third party applications are often found on CDs, and quite often the vendor may not be around any more. While there are many arguments for and against closed source software, the fact is that it exists, and it needs to be installed, maintained, and eventually, removed. A common example of popular third party applications are games. Currently, every vendor has their own method of handling the installation and (optionally) removal of software. This is often handled by scripts, Make files, or an GUI application stored somewhere on the file system, perhaps on the original CD. This is confusing for the end user, and to be brutally honest, it's a mess. While it is possible to statically compile libraries, it's not exactly reasonable to have binary files with every single piece of information required to run a program. Things like icons, sound, data, andconfiguration files all often need to be accessible to the user and other programs. One possibility, that I put forward here, is for a simple install and uninstall system, based around symlinks, and a common applications directory. The application, to all outward appearances in most common file browsers, would appear as a file, but it's really a directory. Let us assume the application is called 'Foo'. Foo consists of binary files, supporting libraries, icons, configuration files usually found in /etc/, and so on. We can express most of these in terms of where they normally fit in the unix file system. A few, mainly icons, and programsshortcuts, vary from environment to environment.
The 'Applications' folder is accessible from the users Control panel as a special directory, allowing write access with sudo and the rootpassword. The folder itself would most likely sit in somewhere > like /usr/local/Applications/. Thus, our application 'Foo', would be in /usr/local/Applications/Foo/. It's file structure would look something like this: /usr/local/Applications/Foo/ /usr/local/Applications/Foo/icon.svg /usr/local/Applications/Foo/description.txt /usr/local/Applications/Foo/main -> ./tree/usr/local/bin/foo /usr/local/Applications/Foo/tree/usr/bin/foo /usr/local/Applications/Foo/tree/usr/lib/foo/libfoo.so /usr/local/Applications/Foo/install/etc/foo/foo.conf /usr/local/Applications/Foo/home/.foo/
To install, symlinks from are made from /usr/bin/foo and /usr/lib/foo/ and /usr/local/Applications/Foo/tree/usr/lib/foo/ to/usr/local/Applications/Foo/tree/usr/bin/foo, and to /usr/local/Applications/Foo/tree/usr/lib/foo/. A copy of /usr/local/Applications/Foo/install/etc/foo/foo.conf is made to /etc/, so that changes made to the configuration do not affect the original files of the program. At the most basic level, Foo/ needs to be copied from it's original source to /usr/local/Applications/ and a script run to copy files in Foo/install/ and make symlinks of the files in Foo/tree/. However, this allows for much greater usability. The file Foo/icon.svg can replace the standard folder icon, and Foo/description.txt can contain multiple language descriptions of the program, to be read by any program used to handle the installation and removal of applications. On moreuser-friendly systems, double clicking on the icon for the program on a CD would prompt the user if they wish to install the program. Attempting to delete the 'program' from the Applications directory would prompt the user if they wish to 'uninstall'. The computer would then remove the symlinks and any configuration files. It also allows the program to ask if the user wishes to remove the system configuration files, originally copied from the the Foo/install/ directory, and user configuration files, originally copied from the Foo/home/ directory. Other benefits of this method come to mind. Source installed packages, for example, Mplayer, instead of being installed directly into the file system, is instead copied into /usr/local/Applications/mplayer/, and installed in the above manner. Mplayer can then be copied easily to other systems, and removed easily. It is also fairly easy to install such applications in systems that do not support it 'natively'. Although a simple shell script is all that is required to 'install' the programs, files can easily be symlinked and copied by hand if need be. I will emphasise again that this system is not meant to replace things link apt-get and rpm, but sit alongside them, and provide a common simple platform independent way of installing third party software.
_______________________________________________ wlug mailing list wlug(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/wlug
Hi. Thank for the feedback. One of the beauties of the system (having now thrown the idea around in a few other places) is that links are set by the file structure. There are several subtrees in Foo/ folder. tree/ - which contains things to be symlinked. Removal of these symlinks is simple reversal of the install process. install/ - which are files that are to copied. Most likely, this would be things like /etc/foo/ home/ - files to be installed - and removed into user home directories. I expect the something like Foo/home/.foo/ would instruct the uninstall script/program to remove the .foo/ directory from any home directories that have the .foo/ directory. This seems obvious, but in some cases, it may be a file, called something other than .foo/ or may be in ~/.kde/share/settings/foo, or similar. common/ - common files to all architectures. tree/ can use some major expansion, most notably along the lines of tree/[os]/[platform]/usr,bin, so you could have seperate files for i386 and PPC, and Linux and BSD all in the same archive/directory. Cheers Edward On Thu, 2003-08-14 at 18:41, Gavin Denby wrote:
I like where you are going, and I promise to read a lot deeper than what I have so far.
Ironically we did something similar with CL 2.1 and 2.3 with the /opt directory. in it we put a lot of the files that a user would normally have in the /home directory (since we didn't know what they would call it), and in many cases it was left there for them to use, without needing to add it to the /home/??? directory.
which was great until they install a package from somewhere else, and ended up with 2 directories, the old stuff cluttering the disk. Such a structure approach, if followed, would make up for the lack of a registry, but I wonder if the installer should also leave an audit trail somewhere that tells you where the file was placed, so that foo's directories can be located when required. ( a registry, without the nightmare of a registry)
On Thursday, August 14, 2003, at 06:13 PM, <edward(a)murrell.co.nz> wrote:
Hi all. Below is a submission for standard that I'm working on. I'd appreciate thoughts, comments, and ideas. Recently, I have been working over strategies for Linux on the desktop. In particular, I've been comparing usability of system administration tasks to Windows 2K/XP and Mac OS X, the main contenders on the desktop. System administration tasks are done by almost everybody who owns a computer. It's not only things like applying security patch's, but includes mundane things like cleaning out old files, changing thedial-up number for your ISP, and installing and removing software.
The last point is a bit of contention under Linux. Sure, apt-get, urmpi, and the like make it easy to get and install the latest open source software from your favourite vendor, but they don't cover 'other'software. Third party, and closed source software is somewhat more difficult.
Third party applications are often found on CDs, and quite often the vendor may not be around any more. While there are many arguments for and against closed source software, the fact is that it exists, and it needs to be installed, maintained, and eventually, removed. A common example of popular third party applications are games. Currently, every vendor has their own method of handling the installation and (optionally) removal of software. This is often handled by scripts, Make files, or an GUI application stored somewhere on the file system, perhaps on the original CD. This is confusing for the end user, and to be brutally honest, it's a mess. While it is possible to statically compile libraries, it's not exactly reasonable to have binary files with every single piece of information required to run a program. Things like icons, sound, data, andconfiguration files all often need to be accessible to the user and other programs. One possibility, that I put forward here, is for a simple install and uninstall system, based around symlinks, and a common applications directory. The application, to all outward appearances in most common file browsers, would appear as a file, but it's really a directory. Let us assume the application is called 'Foo'. Foo consists of binary files, supporting libraries, icons, configuration files usually found in /etc/, and so on. We can express most of these in terms of where they normally fit in the unix file system. A few, mainly icons, and programsshortcuts, vary from environment to environment.
The 'Applications' folder is accessible from the users Control panel as a special directory, allowing write access with sudo and the rootpassword. The folder itself would most likely sit in somewhere > like /usr/local/Applications/. Thus, our application 'Foo', would be in /usr/local/Applications/Foo/. It's file structure would look something like this: /usr/local/Applications/Foo/ /usr/local/Applications/Foo/icon.svg /usr/local/Applications/Foo/description.txt /usr/local/Applications/Foo/main -> ./tree/usr/local/bin/foo /usr/local/Applications/Foo/tree/usr/bin/foo /usr/local/Applications/Foo/tree/usr/lib/foo/libfoo.so /usr/local/Applications/Foo/install/etc/foo/foo.conf /usr/local/Applications/Foo/home/.foo/
To install, symlinks from are made from /usr/bin/foo and /usr/lib/foo/ and /usr/local/Applications/Foo/tree/usr/lib/foo/ to/usr/local/Applications/Foo/tree/usr/bin/foo, and to /usr/local/Applications/Foo/tree/usr/lib/foo/. A copy of /usr/local/Applications/Foo/install/etc/foo/foo.conf is made to /etc/, so that changes made to the configuration do not affect the original files of the program. At the most basic level, Foo/ needs to be copied from it's original source to /usr/local/Applications/ and a script run to copy files in Foo/install/ and make symlinks of the files in Foo/tree/. However, this allows for much greater usability. The file Foo/icon.svg can replace the standard folder icon, and Foo/description.txt can contain multiple language descriptions of the program, to be read by any program used to handle the installation and removal of applications. On moreuser-friendly systems, double clicking on the icon for the program on a CD would prompt the user if they wish to install the program. Attempting to delete the 'program' from the Applications directory would prompt the user if they wish to 'uninstall'. The computer would then remove the symlinks and any configuration files. It also allows the program to ask if the user wishes to remove the system configuration files, originally copied from the the Foo/install/ directory, and user configuration files, originally copied from the Foo/home/ directory. Other benefits of this method come to mind. Source installed packages, for example, Mplayer, instead of being installed directly into the file system, is instead copied into /usr/local/Applications/mplayer/, and installed in the above manner. Mplayer can then be copied easily to other systems, and removed easily. It is also fairly easy to install such applications in systems that do not support it 'natively'. Although a simple shell script is all that is required to 'install' the programs, files can easily be symlinked and copied by hand if need be. I will emphasise again that this system is not meant to replace things link apt-get and rpm, but sit alongside them, and provide a common simple platform independent way of installing third party software.
_______________________________________________ wlug mailing list wlug(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/wlug
_______________________________________________ wlug mailing list wlug(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/wlug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The last point is a bit of contention under Linux. Sure, apt-get, urmpi, and the like make it easy to get and install the latest open source software from your favourite vendor, but they don't cover 'other'software. Third party, and closed source software is somewhat more difficult.
It is possible (and indeed a popular thing to do), to take some commercial software and make a package (either deb/rpm/etc) of it and then install that, thus allowing you to use your usual package management stuff to manage the package. Of course this is pretty difficult for Joe Bloggs, but for an enterprise user this is surprisingly effective.
The 'Applications' folder is accessible from the users Control panel as a special directory, allowing write access with sudo and the rootpassword. The folder itself would most likely sit in somewhere like /usr/local/Applications/. Thus, our application 'Foo', would be in /usr/local/Applications/Foo/. It's file structure would look something like this: /usr/local/Applications/Foo/ /usr/local/Applications/Foo/icon.svg /usr/local/Applications/Foo/description.txt /usr/local/Applications/Foo/main -> ./tree/usr/local/bin/foo /usr/local/Applications/Foo/tree/usr/bin/foo /usr/local/Applications/Foo/tree/usr/lib/foo/libfoo.so /usr/local/Applications/Foo/install/etc/foo/foo.conf
This is a regularly quoted idea. For instance: http://www.sunsite.ualberta.ca/Documentation/Gnu/stow-1.3.2/ Personally I'm not a big fan of the idea of installing into one place, as it means I lose all the benefits of the Unix filesystem. For example: * It's difficult to share content across multiple machines (which may have multiple architectures, eg, a "high scores" across a network of multiple machines. If I share the tree, I get the config files, and binaries and everything. * I can't mount /usr/local readonly to protect against rogue applications/users. etc.
/usr/local/Applications/Foo/home/.foo/
er, what happens if more than one user logs into this machine, perhaps you mean /usr/local/Applications/Foo/home/$USER/.foo/ Then I have to create ..../home/$USER directories for every user I create, and every time I install an application. If I share this across multiple machines then I have to make sure users (and uids) are the same across them all.
To install, symlinks from are made from /usr/bin/foo and /usr/lib/foo/ and /usr/local/Applications/Foo/tree/usr/lib/foo/ to/usr/local/Applications/Foo/tree/usr/bin/foo, and to /usr/local/Applications/Foo/tree/usr/lib/foo/. A copy of /usr/local/Applications/Foo/install/etc/foo/foo.conf is made to /etc/, so that changes made to the configuration do not affect the original files of the program. At the most basic level, Foo/ needs to be copied from it's original source to /usr/local/Applications/ and a script run to copy files in Foo/install/ and make symlinks of the files in Foo/tree/. However, this allows for much greater usability. The file Foo/icon.svg can replace the standard folder icon, and Foo/description.txt can contain multiple language descriptions of the program, to be read by any program used to handle the installation and removal of applications.
This sounds very NeXTish where if a "directory" had a ".app" extension then the GUI treated it like an entire application. MacOS X has "stolen" this idea with their "bundles".
I will emphasise again that this system is not meant to replace things link apt-get and rpm, but sit alongside them, and provide a common simple platform independent way of installing third party software.
An interesting idea, however I think it more likely that people will start packaging RPM's than some other format. - -- People who push both buttons should get their wish. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Only when you are sure they have you, can you stop being paranoid iD8DBQE/OzFgcAgRpy8z8UQRAmptAKCsaa0lLJzu80C9hwtLwC9dvXioZACfT0QH YkCSGqbvhH3inVbxn+XatL4= =tjNU -----END PGP SIGNATURE-----
On Thu, 2003-08-14 at 18:51, Perry Lorier wrote:
It is possible (and indeed a popular thing to do), to take some commercial software and make a package (either deb/rpm/etc) of it and then install that, thus allowing you to use your usual package management stuff to manage the package. Of course this is pretty difficult for Joe Bloggs, but for an enterprise user this is surprisingly effective.
Indeed, however, I doubt that software companies are going to produce it for every platform. This would (in theory) be platform independent. Anyone would be able to add the few scripts required to make it 'compatible' with their system.
This is a regularly quoted idea. For instance: http://www.sunsite.ualberta.ca/Documentation/Gnu/stow-1.3.2/
Will read. Still waiting for it to actually download though.
Personally I'm not a big fan of the idea of installing into one place, as it means I lose all the benefits of the Unix filesystem.
For example: * It's difficult to share content across multiple machines (which may have multiple architectures, eg, a "high scores" across a network of multiple machines. If I share the tree, I get the config files, and binaries and everything.
Good point. What would be the proper way of doing this in the traditional manner? I'm assuming it would be something along the lines of a file in /etc/. As added in my other post, and install/ directory would be added for files that are copied/written to. In theory, I'm guessing you could 'install' from a CD - although that's an non-thought out off the cuff comment. :P
* I can't mount /usr/local readonly to protect against rogue applications/users.
etc.
/usr/local/Applications/Foo/home/.foo/
er, what happens if more than one user logs into this machine, perhaps you mean /usr/local/Applications/Foo/home/$USER/.foo/
Then I have to create ..../home/$USER directories for every user I create, and every time I install an application.
Well, the idea is that the /usr/local/Applications/ directory is read only, (except for when the software is installed/removed of course).
If I share this across multiple machines then I have to make sure users (and uids) are the same across them all.
See other reply to Gavin Denby with the install/ subdirectory, and the home/ subdirectory.
This sounds very NeXTish where if a "directory" had a ".app" extension then the GUI treated it like an entire application. MacOS X has "stolen" this idea with their "bundles".
I will emphasise again that this system is not meant to replace things link apt-get and rpm, but sit alongside them, and provide a common simple platform independent way of installing third party software.
Well, I did get the idea from when I was playing around with the terminal on a Mac. :) Cheers for the thoughts. I'll read that site when it's accessible again - it appears to be down at the moment. Regards Edward
participants (4)
-
Edward Murrell -
edward＠murrell.co.nz
-
Gavin Denby -
Perry Lorier