Planning for Future Upgrades

The information in this section is currently under review; please forward any additions, deletions, or corrections to Devin Reade.

One of the concerns for a system that is as large and as complex as GNO is how to keep it updated without losing any custom configuration that been added locally since the last installation. This section attempts to document how to minimize such conflicts and, where the conflicts can't be avoided, where they are likely to occur.

In the context of updating GNO, there are three main sets of files. The first one is anything that is in the /usr/local hierarchy. The subdirectories and files under /usr/local are intended strictly for site-specific customization. The GNO base distribution does not, and never will, add or modify files within /usr/local. (It may, however, ensure that certain subdirectories exist.) For this reason, it is recommended that any files (such as programs, configuration files, or manual pages) that you wish to have on your system but are not part of the GNO base distribution are placed within the /usr/local hierarchy. If you wish to have this customation available to another GNO installation, it would then be sufficient to copy the /usr/local hierarchy in its entirety.

NOTE: There is a single (temporary) exception to the comments above. The current GNO base distribution will copy in the file /usr/local/lib/startup.mk which is used by the program dmake, and which is a duplicate of /usr/lib/startup.mk. When dmake gets updated to properly use /usr/lib/startup.mk as it's configuration file, then /usr/local/lib/startup.mk will no longer be created by the GNO base install scripts. If you have customized /usr/local/lib/startup.mk for your site, you first save your startup.mk file elsewhere, then merge those customizations into the new startup.mk.

The second set of files are those which have been written such that they (or their configuration files) have pathnames which are hardcoded, and therefore must reside outside of the /usr/local hierarchy. Some of these programs can be forced into the first set described above by setting appropriate environment variables; see the program's documentation for details. For the remainder, you should keep track of which programs you have installed, and where they (or their configuration or data files) reside. Unless there is a name conflict with files in the GNO base distribution, these files won't be overwritten or deleted during a GNO update, but they obviously will not be copied in when doing a “from scratch” installation.

The third set of files are those are created while installing the GNO base distribution, but which almost certainly have been modified in any existing GNO site. These are all configuration files of one sort or another. (If you are doing a fresh install, you can ignore this set.) If you are using the GNO “from scratch” installation scripts rather than the update scripts (not yet available) then you must ensure that you have backups of these files so that you can restore them after the install scripts have completed. You should not merely copy your old versions over the new ones; instead compare the old files to the new to verify if there have been features added which should be propagated to your old customized files.

The files which are known to be in the third set are listed here:

	/etc/glogin
	/etc/group
	/etc/hosts
	/etc/inittab
	/etc/motd
	/etc/networks
	/etc/namespace
	/etc/passwd
	/etc/rchost
	/etc/syslog.conf
	/etc/whereis.conf
	/home/root/gshrc
	/lib/orcacdefs/defaults.h
	/var/adm/newuser/newid
	/var/adm/newuser/skel/glogin
	/var/adm/newuser/skel/gshrc

If you find that you have to modify any files outside of the /usr/local (or /home) hierarchy, you should record which files have been so modified, together with a brief description of the necessary changes.