--- In firstname.lastname@example.org
, "joule360" <joule360@y...> wrote:
> I am currently planning to keep all config data in the conf
> partition, using standard linux layout (/etc, /etc/rc.d, etc) and
> create /bin, /sbin, /usr/bin, /usr/sbin on the data partition, and
> per standard linux layout. My modified rc.local will then create
> necessary symlinks to the proper executables from (eg
> from /usr/bin/<frotz> to /hdd/share/data/usr/bin/<frotz> as part of
> the startup sequence.
I don't want to be the "Filesytem Layout Thought Police" :-), but I
do think that we should get this right before we go much further into
expanding the range of UNSLUNG packages available.
The rational for following the Linux Filesystem Heirarchy Standard
(FHS) is that is guarantees that we can put multiple packages on the
hard disk and not have them collide with each other.
Here are the descriptions for the directories in question (all of
which would be physically stored on the hard disk, but symlinked or
mounted onto the root filesystem):
> > /usr/local
> > /etc/local
These (/usr/local and the corresponding /etc/local) are meant for
stuff that you are compiling and testing out on your machine only.
The FHS says that you shouldn't release packages that install into
these areas. /usr/local has the usual structure (bin,lib,man) under
> > /opt
> > /etc/opt
> > /var/opt
These (/opt and the corresponding /etc/opt) are meant to be where
installable packages put themselves. /opt has subdirectories which
are uniquely named according to the developer's or package's name (to
guarantee there are no collisions). This also makes it very easy to
install and uninstall packages (just untar or delete whole
directories). Each of the package directories has the usual
structure (bin,lib,man) under it. Then there is a mechanism to
enable a package, which persists across reboots. More on that in
another post tomorrow.
> > /var/log
> > /var/mail
> > /var/spool
> > /var/tmp
These places are for things that you want to preserve across reboots.
If we get this correct up front, then we can go forward in populating
the UNSLUNG downloadable package repository with packages that are
easy to install (requiring little or no manual intervention, and
certainly not needing manual edits to common files), easy to remove
(run a command to disable the package, then delete the package's
directory), guaranteed not to collide with other packages, and will
still be available and working after we release a new base firmware
package corresponding to a new Linksys firmware release.
What do people think about this idea?