Usr Move - More, Please

[Kevin Kofler]

Mike Pinkerton wrote:
> 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.

That would break consolehelper among other things.

> 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 don't get how your nonstandard /app is any different from the standard 
/opt, i.e. why your distinction is needed. You seem to suggest that 
/usr/local should be a symlink to /opt, but that's misunderstanding how /opt 
is expected to work. /opt is supposed to work like your /app, /usr/local is 
supposed to work like your /opt. So the distinction you apparently want 
already exists, there is no need to come up with new non-FHS directories. It 
is already common and recommended practice to install to /opt/appname, not 
to /opt directly, that's the difference between /opt and /usr/local! 
Anything installing directly to /opt (i.e. putting e.g. binaries into 
/opt/bin) is abusing /opt and needs to be fixed.

I also don't think that the "app" model is something we should encourage, at 
all (package management exists for a reason!), but that is fairly irrelevant 
for this discussion because the model is already covered well by /opt.

> 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.

That is not possible without patching all the applications.

FWIW, KDE applications already do this, in fact we have 4 layered 
directories of configuration, in increasing order of priority:
* /usr/share/config: upstream defaults, installed by the package itself
* /usr/share/kde-settings/kde-profile/default/share/config/: Fedora 
defaults, installed by the kde-settings package
* /etc/kde: machine defaults, put in place by the local system administrator
* ~/.kde/share/config: per-user settings, made by the individual user

But most applications' configuration systems are not as flexible as KConfig 
and therefore cannot support this model without (heavy) patching. (Actually, 
we have to patch even KConfig to support the 4 layers! But the patch is very 
small because KConfig already has a concept of resource search paths. Most 
configuration systems are hardcoded to only look in /etc and/or some place 
in the user's home directory. And many of those systems are only used by one 
piece of software, so there would be a lot of code to patch.)

So your non-FHS "conf" directories just cannot be arbitrarily implemented by 
a distribution where the upstream code doesn't support the concept.

        Kevin Kofler