I am late to the game but wanted to thank Harald and Kay for their
efforts, and to encourage them to go even further.
History has brought us to a point where there are at least 7 standard
places to put binaries (not counting ~/bin):
/bin
/opt
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
plus a handful more locations for libraries.
I accept your premises that the historical reasons for this division
of binaries are no longer compelling, that the present variety of
locations is confusing and works against cross-distro compatibility
and that simplification is a good thing in itself. I encourage you
to simplify things further by merging /usr/sbin into /usr/bin.
While the reasons for the current categorization of binaries are no
longer compelling, I think there is a case to make for a new division
of binaries. Specifically, it is useful to separate those programs
that are managed by a package management system from those that are
not. Additionally, "app" style programs will become more common in
the future, whether on a portable or a desktop. Those "app" style
programs are the only way one can create a central marketplace for
small, easily downloaded and installed, distro-agnostic programs.
Such a marketplace will become increasingly important to the vitality
of any computing platform, including Linux. Keeping "apps" separate
from managed and locally-compiled programs would be useful.
I like the general approach that systemd has taken to configuration
-- putting most of its default configuration in /lib/systemd and
allowing host-specific entries in /etc/systemd to override them. I
would like to see programs (including systemd) adopt a more rigorous
version of that approach -- with all default configuration in /usr.
The result would be that, immediately after installation, /etc would
be empty.
So here is my suggestion:
/app (host specific "app" style programs -- "drag-and-drop"
installed
programs wholly contained within a single directory
tree with no
dependencies outside that tree -- and which include
defaults that
can be overriden by configuration in an user's home
directory)
/etc (host specific configuration -- overrides all defaults --
package manager cannot write to this directory)
/opt (unmanaged software -- both site and host specific)
/bin
/conf (all site or locally-compiled programs would put their
default
configuration files here)
/lib
/usr (managed software -- both distro and site packaged)
/bin
/conf
/distro (distro default configuration files)
/site (site default configuration -- overrides distro
defaults)
/lib
With this directory structure, as a site administrator I can package
my own site-wide configuration files, put them in a local repo, and
override the distro default configuration. By limiting /etc to host-
specific configuration, I maintain a clean separation of:
+ distro-default configuration files, which are never edited,
and which are updated as distro packages are updated,
+ my site-default configuration files, which are never edited,
and which are updated from my local repo, and
+ host-specific configuration files, which would probably only
be necessary for a handful of programs per host.
This approach also makes backing up easier. There is no need to back
up any part of /usr -- it can be re-installed from repos, if it is
not being mounted from a remote server.
On a server, one would need to back up unmanaged software from /opt,
host-specific configuration from a much slimmed-down /etc, and data
files from /srv and /var.
On a portable or desktop, /opt will probably be empty, /var will be
expendable, and one would just need to back up /app, a much slimmed-
down /etc, and /home, which should contain users data files and user-
specific configuration for apps.
This suggestion creates one new top-level directory, keeps the
confusing historical names for compatibility purposes, and turns at
least 5 current directories into symlinks:
/bin -> /usr/bin
/sbin -> /usr/bin
/lib -> /usr/lib
/usr/local -> /opt
/usr/sbin -> /usr/bin
Bottomline, congratulations Harald and Kay on a good first step to
simplifying and rationalizing the file structure. Now keep going.
--
Mike Pinkerton
Kool-Aid Drinker
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
