4:53 p.m.
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
11:17 p.m.
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
8:38 a.m.
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
9:01 a.m.
On 01/30/2012 03:38 PM, Mike Pinkerton wrote:
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.
Unifying package management across distros would a Good Thing (tm). Once
there's a unified interface to the package management system, you can
envision things like app marketplaces that simply instruct the
distribution to install that distribution's package of a particular app.
Clicking "Firefox" would do "yum install firefox" on fedora and
"apt-get
install firefox" on Ubuntu. Let us do everything in our power to make
this happen!
Two things that are not a good thing
- Installing software outside of the package management system (instead,
get the package included in fedora or rpmfusion)
- Statically linked libraries or 'bundled' libraries (See:
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries )
As for propietary software, there's nothing the open source community
can do to influence the design decisions of proprietary software vendors.
11:01 a.m.
On 30 Jan 2012, at 10:01, Emanuel Rietveld wrote:
On 01/30/2012 03:38 PM, Mike Pinkerton wrote:
>
> 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.
>
Unifying package management across distros would a Good Thing (tm).
Once there's a unified interface to the package management system,
you can envision things like app marketplaces that simply instruct
the distribution to install that distribution's package of a
particular app. Clicking "Firefox" would do "yum install firefox"
on fedora and "apt-get install firefox" on Ubuntu. Let us do
everything in our power to make this happen!
If I understand you correctly, you are suggesting that a third party
app marketplace, offering both open source and proprietary apps,
would maintain multiple repos for apps based on distro, version and
arch, and then implement the download of the appropriate version by
utilizing the existing package management system, making apps part of
the system's managed software.
To make something like that viable, your app marketplace would
probably also need to provide a packaging infrastructure to app
developers that would enable them to build packages for all covered
distros, versions and archs without actually having to learn each of
the packaging systems.
As for propietary software, there's nothing the open source
community can do to influence the design decisions of proprietary
software vendors.
What you can do, however, is recognize that, if given the
opportunity, your user base will download and install "app" type
programs, and that it would be better to provide an appropriate place
within the file system to place those apps. My suggestion -- which
assumed that apps would not be managed by the package management
system (because users will do what users do) -- was that an
appropriate place would segregate "app" type programs from both
managed software and locally-compiled software. Segregation would
make housekeeping easier given the different update and back-up
strategies that might be appropriate for "app" type programs.
To return to your suggestion, but modify it a bit, perhaps there
needs to be an unified interface for downloading, installing and
launching "app" type programs that would (1) know where in a
particular distro's file system they should be installed, and (2)
provide easy access to "app" type programs from whichever GUI the
user employs.
--
Mike Pinkerton
the Kool-Aid tastes great
5:44 p.m.
On Mon, 2012-01-30 at 16:01 +0100, Emanuel Rietveld wrote:
On 01/30/2012 03:38 PM, Mike Pinkerton wrote:
>
> 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.
>
Unifying package management across distros would a Good Thing (tm). Once
there's a unified interface to the package management system, you can
envision things like app marketplaces that simply instruct the
distribution to install that distribution's package of a particular app.
We already have that. It's called PackageKit (no, PackageKit is not
actually a GUI package installer application, though that seems to be a
common misunderstanding). It's sadly under-used for this, which you
would think would be a significant purpose.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:12 p.m.
2012/1/30 Mike Pinkerton <pselists(a)mindspring.com>
[...]
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.
Why doesn't /usr/local fit anymore? It was especailly designed for this
kind of setup. It will not fit if you define everything underneath /usr as
managed software, but FHS didn't do this in the past and nearly all
distributions I know didn't work like this.
Because /opt is the only other current directory that makes sense
for
locally-compiled programs, I would symlink /usr/local -> /opt.
This could be an option, but several commercial programs use something like
/opt/appname what is also valid FHS style. If you symlink /usr/local you
could end up an a mixed /opt/lib, /opt/bin, /opt/appname thing.
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.
FHS is a recommendation, nothing more and nothing less. It should only help
to find a common base for all distributions like LSB does. But this also
implicate that it won't help if only one distribution change the whole FHS
style without having the other distributions involved. So putting all
binaries to an already defined location within FHS is one thing, but having
several new locations is a complete other story an much harder to realize.
Regards Thomas
--
Linux ... enjoy the ride!
7:45 p.m.
Mike Pinkerton wrote:
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.
Then symlink it to /opt/local or just /local. Or maybe /var/local.
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.
It's a convention also honored by the third-party crap which installs to
/opt. (And yes, I consider binary blobs which bypass our package management
to be crap. Even more so if they're proprietary.)
> 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.
No, thankfully we do not have any crappy app stores yet in GNU/Linux and I
want it to stay that way!
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).
You can't get any easier than installing from Apper or gnome-packagekit.
Pick your package, click Install, click Apply, confirm dependencies if any
(just click OK, and at least Apper also offers you a "Don't ask again"
option there), enter the root password (something you'd also have to do to
install a crappy blob into /opt) and there you go! (And you can also
configure PolicyKit so that it allows you to install packages through
PackageKit without a password. In fact that was the default in Fedora 12 as
shipped, but got disabled in an update because it was deemed too lax a
default policy.)
By bundling most of their dependencies,
Yuck! That's exactly why bypassing the package management system is a
HORRIBLE idea! The system resolves the dependencies for you, use it!
App stores are technically inferior to repositories with dependency
resolution. We already have the latter, so why would we support the former
in any way?
"app" type programs become one way to create a cross-distro
"app"
marketplace.
"Market" as in you have to PAY for your apps? No thanks! I like my
repositories where everything is free of charge!
And I also don't like proprietary software, so I don't personally use RPM
Fusion Nonfree even though it is also free of charge. An app store which
makes it easy to distribute binary blobs would also promote proprietary
software. No thanks! The current repository system also strongly encourages
shipping your software under a Free Software (as in Free Speech) license
(which allows packagers to compile it for distributions from source and
those distributions to ship the packages in their repositories with no nasty
strings attached).
If we end up with separate "app" marketplaces for Fedora,
SUSE,
Debian, Ubuntu, et alios, they are all going to languish.
That assumes we want such marketplaces in the first place. I definitely
don't want cross-distro blobs built for the lowest common denominator with
every single library bundled. (Not even if they're binaries of Free
Software! That method of distribution is just technically awful, provides
poor to no system integration (menu entries etc.) and needlessly wastes my
bandwidth and disk space.)
On the other hand, a single "app" marketplace for
mainstream Linux distros
might well prosper.
So that's another reason not to support this. :-p
We need to send a clear message that if you want to get your software out to
Fedora users, it must get into the Fedora repository! That way:
* the software must be appropriately licensed (Free as in Free Speech),
guaranteeing the freedom to use, study, modify and redistribute (with or
without charging for it) the software at will,
* the packaging must be up to Fedora standards, following Fedora policies,
not some cross-distro lowest common denominator (which invariably causes
problems, e.g. proprietary software RPMs often disable RPM's automatic
dependency extraction for some reason, so you can install them without the
required libraries and they obviously won't actually work that way!), and
* users get the software free of charge.
It's not upstream's job to ship binaries, it's the packagers'!
Upstream's
job is to ship source code for distributions to package in their
repositories. We should not make it easier for upstreams to ship binary
blobs.
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.
As I wrote above, /opt/local makes more sense than plain /opt.
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.
Unifying the configuration systems of all applications and daemons has been
attempted several times, e.g. by the Elektra project:
http://www.libelektra.org/ , so far with very limited success. (Few to no
upstream projects picked up their patches.) So we're stuck with the current
ad-hoc solutions, which do not support such a cascading hierarchy.
Kevin Kofler
4478
days inactive
4480
days old
7 comments
5 participants
participants (5)
-
Adam Williamson -
Emanuel Rietveld -
Kevin Kofler -
Mike Pinkerton -
Thomas Bendler