Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

[Rich Freeman]

On Fri, Feb 28, 2014 at 10:59 AM, hasufell <hasufell@g.o> wrote:
> Despite that... the answer is already here:
> http://devmanual.gentoo.org/general-concepts/filesystem/index.html
>
>> Gentoo does not consider the Filesystem Hierarchy Standard to be an
>> authoritative standard, although much of our policy coincides with
>> it.
>
> So this is not really something the council has to decide on, unless
> you propose to change that policy altogether.

As far as what the new policy should be goes, a lot has developed in
the linux world post-FHS.  The biggest one is the whole /usr-move
direction that many distros seem to generally be moving in.  Vertical
integration complements this (making booting without /usr a
challenge).  Initramfs has also come along and has basically turned
into a userspace bootloader of sorts.

The whole config-files-in-/usr thing is also driven by this, and also
by the desire of distros to avoid something like etc-update.  We do
the same thing with make.defaults, which doesn't go in etc (though to
be fair it is linked from there, sort-of).

The general direction of projects like systemd, the /usr-move, config
files in /usr, and so on fix real problems on most distros.  I think
one of the challenges for Gentoo is that many of these problems are
ones that Gentoo has already fixed, somewhat.  So, for us it isn't
about moving from a gaping hole into a workable solution, but moving
from one solution we're already accustomed to into another new
solution that might or might not be somewhat better, and which likely
involves some tradeoffs.  For anybody using a non-dependency-aware
service manager systemd is a huge improvement, for an openrc user the
benefits really aren't that dramatic, though I suspect for laptop
users it could be a step up once it matures.

Gentoo is also not release-oriented, so the /usr-move doesn't really
carry the same benefits.  If you are release-oriented and have
completed the /usr-move then upgrading your distro might be equivalent
to symlinking /usr to a zero-seek-time CD drive, and swapping out the
disc, kernel, and initramfs.

I think the real issue for Gentoo is the cost of doing things
differently.  Right now we're just looking at that in terms of how
hard it is to stick a doins in an ebuild, but that is just the
starting point.  Once you start getting vertical integration then you
run into a myriad of things being done differently vs upstream, and
that can snowball.  You have to ask what we're getting for all of
that.  Is the world a better place if Gentoo sticks config defaults in
/etc/default vs wherever upstream puts them?  Is there value in having
those defaults clogging your /etc scm or whatever you're using to
manage config, when it is already managed by your package manager?

I'm all for an evolution of FHS that helps address some of these
questions, but that really isn't something we can do at the distro
level.  It would take working WITH all of those newfangled projects
that are doing things that annoy us, finding ways to standardize
across distros while still giving the binary distros what they need.
A distro like Ubuntu isn't going to buy into the concept that
etc-update makes their problems moot.

I think Gentoo needs to stick to being different where being different
really adds value.  That means rolling releases, flexibility around
dependency versioning, control over build-time options, flexibility
around system components whenever practical, and so on.  We can't
really afford to fight WW3 over where some config file gets installed,
or what its filename is.  We can't afford to build a Gnome3 that works
without systemd (at least, not for long), and so on.  What we can do
is support any forks/clones/etc that have a sustainable community
around them (such as eudev, openrc, etc).

Finally, this is a volunteer distro - contributions get you a lot
further than criticism.  So, publish all the
forks/overlays/alternates/etc you want, and by all means solicit
support for them.  Once upon a time few ebuilds had systemd units,
looking at the tracker now that is mostly limited to packages that
I've never heard of.  All it takes for an option to remain viable is a
few people who care enough to steadily contribute.

Rich