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