On 30 Jan 2012, at 00:17, Kevin Kofler wrote:
Mike Pinkerton wrote:
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.
If (1) we mount /usr ro over the network, and (2) we want /usr to be
reserved for managed software (for a variety of reasons), then /usr/
local really doesn't fit anymore.
Because /opt is the only other current directory that makes sense for
locally-compiled programs, I would symlink /usr/local -> /opt.
I understand that the FHS recommends installing to /opt/appname, but
there is no enforcement of that. Currently compliance is a matter of
local policy.
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.
You might not want to encourage the "app" model, but that boat
already left the dock. For Linux distros to be players on portables
and desktops, they need to recognize that there is an appetite among
the user base for "app" type programs that are easy to install (drag-
and-drop). By bundling most of their dependencies, "app" type
programs become one way to create a cross-distro "app" marketplace.
If we end up with separate "app" marketplaces for Fedora, SUSE,
Debian, Ubuntu, et alios, they are all going to languish. On the
other hand, a single "app" marketplace for mainstream Linux distros
might well prosper.
I would keep "app" type programs separate from locally-compiled
programs. With different update and back-up strategies for the two
types of programs, the separation makes housekeeping a lot easier.
If you prefer /opt/app and /opt/local, and symlink /usr/local -> /opt/
local, that would work for me.
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.
I understand. I think the concept of "cascading configuration files"
is useful enough, though, that it would be a worthwhile goal.
Perhaps when he finishes with systemd, Lennart can figure out how to
interpose a generalized configuration cascader that would ease the
pain. And, yes, I appreciate all the good work Lennart has been doing.
--
Mike Pinkerton
Still drinking the Kool-Aid
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
