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

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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Samuli Suominen:
> 
> On 28/02/14 13:15, Patrick Lauer wrote:
>> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
>>> Hi everyone,
>>> 
>>> I'm putting the call out there for any agenda items for the
>>> next Council meeting, which will be held on March 11, 2014 at
>>> 1900 UTC.  This is short notice but we got off track because of
>>> FOSDEM and we're going to try to get back on track.
>>> 
>>> So far, the only item is final ratification of glep 63 [1].
>> Since it's still a bit cold I'd like to start a nice fire to warm
>> us up:
>> 
>> I'd like QA and Council to figure out how much we care about
>> FHS.
>> 
>> My main complaint is some projects (including e.g. systemd and 
>> apparently now also udev) storing config files in /lib and/or
>> /usr/lib.
>> 
>> From FHS' point of view this is totally wrong, config files go to
>> /etc Only libraries should be in /lib.
> 
> Wow. What about libtool .la text files? What about kernel modules? 
> What about the genereted modules.* data in /lib/modules/$version/
> which are used in early boot by eg. kmod-static-nodes? What about
> the binaries of OpenRC in /lib/rc, they aren't libraries? And what
> about vendor modprobe.d files in /lib/modprobe.d? I could continue
> this all day. I'm just trying to point out "Only libraries should
> be in /lib." is complete bs and does not work. Does FHS really
> articulate it the way you said it, "Only libraries should be in
> /lib." or was that your own interpretation of it?
> 
> I'm not really expecting an answer as I'm already convinced FHS is
> so badly outdated it's sad it doesn't suit modern systems. I hope
> they will catch up at some point.
> 
> - Samuli
> 

In addition to the questions of Samuli...

What about python, perl, ruby and whatnot script languages.
What about haskell and pascal? Some of them files are reported to be
"data" files.
What about erlangs .erl and .hrl (text)?
What about mono/C# .exe and .dll (are they architecture-dependant or
can I treat them as "data files" and move them to "/usr/share/"?)
What about non-trivial packages like fpc, firefox, portage and
libreoffice that all violate FHS? Who will fix it and maintain that
stuff downstream?
What about /opt, we don't follow that either?

What about /usr/include and ".hpp" files (only C is valid according to
FHS)? Who will fix boost?

I skip the part of running some funny "find" commands on my local system.

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.
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJTELJnAAoJEFpvPKfnPDWzjGwIAK1rEmYgKodNs4OT1cHJWinA
A+cWLepzDPMRKr7cPtt6UCYsZP1hidYW/vIrTTI8XynYEkTsSNaawtk6JJLN6qAD
8E0TXZJN8flH5nu7rBVaxJ1liEAEy/qmYMqs5wfI64sYoqOuIiScpk/CjWPMoGob
7UZuxbBhJGnt+/VsgVeor1GZM+dQ2ygBnp9g9A7QjfsIpBitGjSQvYet9z1O01OP
T/SXPiti/yTbz3Au17GLaxQrbK9Kp6Qi676B544S1z9wkXClXJiWV8yD2BcfcX9T
GmfqKNb3Mna2qyLIpZ96nDy28eJpvEA6X72lRpPhJqMEHr+1+vqQQn5Uc8F+4ak=
=gGfE
-----END PGP SIGNATURE-----

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@gentoo.org> 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

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]

On Fri, Feb 28, 2014 at 03:59:35PM +0000, hasufell wrote:

*snip*

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

Agreed.

Gentoo has never considered the fhs to be authoritative. It is a guide.
If we can follow it we do, if we can't we don't. There is nothing to
change here unless you are asking that we make fhs authoritative, which
I would be firmly against.

Regarding the comments blueness made on -project about the /->/usr merge
violating fhs, I have spoken with vapier about this myself on several
occasions, and his position is exactly the opposite; it does not violate
fhs.

You might also want to read this article on osnews about why the split
happened; there is definitely interesting information here [1]. The
reason the split happened is pretty straight forward, and every other
"justification" for continuing it was come up with after the fact.

William

[1]
http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[David Leverton]

William Hubbs wrote:
> The reason the split happened is pretty straight forward, and every other
> "justification" for continuing it was come up with after the fact.

I keep hearing this, but I really don't see how it's relevant.  I'm sure 
you'll find lots of things in your life that you use for some purpose 
other than what they were originally invented for¹, and there's no 
reason why /usr should be any different.  All that matters is whether or 
not the newer reasons for having separate /usr actually provide a benefit.

[1] http://en.wikipedia.org/wiki/Coca-Cola#19th_century_historical_origins

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Fri, Feb 28, 2014 at 09:57:15PM +0000, David Leverton wrote:
> William Hubbs wrote:
> > The reason the split happened is pretty straight forward, and every other
> > "justification" for continuing it was come up with after the fact.
> 
> I keep hearing this, but I really don't see how it's relevant.  I'm sure 
> you'll find lots of things in your life that you use for some purpose 
> other than what they were originally invented for¹, and there's no 
> reason why /usr should be any different.  All that matters is whether or 
> not the newer reasons for having separate /usr actually provide a benefit.

And I would argue that the maintenance cost of having separate /usr in a
general sense is much higher than the benefit it provides.

The problem with it is that it is next to impossible nowadays to define
what should go in / vs what should go in /usr.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alon Bar-Lev]

On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs <williamh@gentoo.org> wrote:
>
> On Fri, Feb 28, 2014 at 09:57:15PM +0000, David Leverton wrote:
> > William Hubbs wrote:
> > > The reason the split happened is pretty straight forward, and every other
> > > "justification" for continuing it was come up with after the fact.
> >
> > I keep hearing this, but I really don't see how it's relevant.  I'm sure
> > you'll find lots of things in your life that you use for some purpose
> > other than what they were originally invented for¹, and there's no
> > reason why /usr should be any different.  All that matters is whether or
> > not the newer reasons for having separate /usr actually provide a benefit.
>
> And I would argue that the maintenance cost of having separate /usr in a
> general sense is much higher than the benefit it provides.
>
> The problem with it is that it is next to impossible nowadays to define
> what should go in / vs what should go in /usr.
>
> William

Now it is difficult as too much time it was ignored.

In the past it was quite simple, everything that requires a server to
reach default runlevel.

The problem is that instead of telling users: "If you are using
special user mode devices,  such as bluetooth keyboards, please make
sure /usr is mounted at boot", we enforce all that configuration, so
now initramfs should contain all that once was / with much harder
maintenance.

Alon

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

[David Leverton]

William Hubbs wrote:
> And I would argue that the maintenance cost of having separate /usr in a
> general sense is much higher than the benefit it provides.

That's a legitimate point (not that I necessarily agree or disagree as 
I'm not the one who's tried to make it work) - perhaps I should have 
acknowledged that it's still a trade-off.  I'm just trying to get rid of 
the meme that whatever benefits do exist somehow don't count because 
they weren't planned in the original Unix design.

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

On Sat, Mar 01, 2014 at 12:24:02AM +0000, David Leverton wrote:
> William Hubbs wrote:
> > And I would argue that the maintenance cost of having separate /usr in a
> > general sense is much higher than the benefit it provides.
> 
> That's a legitimate point (not that I necessarily agree or disagree as 
> I'm not the one who's tried to make it work) - perhaps I should have 
> acknowledged that it's still a trade-off.  I'm just trying to get rid of 
> the meme that whatever benefits do exist somehow don't count because 
> they weren't planned in the original Unix design.

Actually we are digressing heavily (I'm guilty too), the original point
of this thread was about the fhs and how tightly we are supposed to
follow it.

Patrick thinks that all configuration files belong in /etc, and what has
happened is, some packages are placing default configuration
files in /lib or /usr/lib and allowing them to be overridden by files
with the exact same names and paths in /etc. His argument is that only
libraries belong in /lib or /usr/lib.

I disagree with this based on understanding how the config system in
these packages works. Also, I don't think a distro should do this type of
patching if the patches are not accepted upstream.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Wyatt Epp]

On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> Patrick thinks that all configuration files belong in /etc, and what has
> happened is, some packages are placing default configuration
> files in /lib or /usr/lib and allowing them to be overridden by files
> with the exact same names and paths in /etc. His argument is that only
> libraries belong in /lib or /usr/lib.
>
I didn't get that vibe from what was quoted in OP.  Maybe there's
something missing.  But let's be real here: if I install something and
want to configure its system-wide bits, the first place I go is ALWAYS
/etc.  When I don't find it there, with the rest of the system config
files, my day gets a little worse and I lose a bit of time trying to
interrogate a search engine for the answer.  And that's annoying.
That sucks.

I don't particularly care about the history, or the politics, or what
upstreams think they have the right to decide for me.  Sure, it might
be "only" convention, but even then it's still valuable by merit of
allowing you to make (often correct) predictions about where to
configure your shiny new daemon and by reducing cognitive load (no
need to remember that "Okay, so bonehead has its config in
/usr/lib/bone/head/ and sillyd has it's config in /var/silly/comedy/,
and...where was riced.conf, again?").

> I disagree with this based on understanding how the config system in
> these packages works. Also, I don't think a distro should do this type of
> patching if the patches are not accepted upstream.
>
I somehow get the sense that you're talking about specific packages,
but more generally: If there's some legitimate reason the config can't
go where configs...go (like the package hardcoding the path to the
config without any overrides possible (which sounds absolutely
moronic, IMO.  What if you want to temporarily test a new config?))
then sure, let it live where it lives.  But for stuff where they're
already able to be overridden by a version in /etc anyway?  I don't
think "if users are supposed to be able to modify it, the config
should be /etc" is an unreasonable position to take.

Reducing user pain isn't an all-or-nothing exercise.

Cheers,
Wyatt

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs <williamh@gentoo.org> wrote:
> >
> > Patrick thinks that all configuration files belong in /etc, and what has
> > happened is, some packages are placing default configuration
> > files in /lib or /usr/lib and allowing them to be overridden by files
> > with the exact same names and paths in /etc. His argument is that only
> > libraries belong in /lib or /usr/lib.
> >
> I didn't get that vibe from what was quoted in OP.  Maybe there's
> something missing.  But let's be real here: if I install something and
> want to configure its system-wide bits, the first place I go is ALWAYS
> /etc.  When I don't find it there, with the rest of the system config
> files, my day gets a little worse and I lose a bit of time trying to
> interrogate a search engine for the answer.  And that's annoying.
> That sucks.

This hasn't changed.
The configuration files these packages are putting in /lib are not
meant to be edited; they are the package provided defaults. If you want
to override one of them, you do that in a file with the same path and
name in /etc, like I mentioned in another message in this thread.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Joshua Kinard]

On 02/28/2014 7:47 PM, William Hubbs wrote:
> On Sat, Mar 01, 2014 at 12:24:02AM +0000, David Leverton wrote:
>> William Hubbs wrote:
>>> And I would argue that the maintenance cost of having separate /usr in a
>>> general sense is much higher than the benefit it provides.
>>
>> That's a legitimate point (not that I necessarily agree or disagree as 
>> I'm not the one who's tried to make it work) - perhaps I should have 
>> acknowledged that it's still a trade-off.  I'm just trying to get rid of 
>> the meme that whatever benefits do exist somehow don't count because 
>> they weren't planned in the original Unix design.
> 
> Actually we are digressing heavily (I'm guilty too), the original point
> of this thread was about the fhs and how tightly we are supposed to
> follow it.
> 
> Patrick thinks that all configuration files belong in /etc, and what has
> happened is, some packages are placing default configuration
> files in /lib or /usr/lib and allowing them to be overridden by files
> with the exact same names and paths in /etc. His argument is that only
> libraries belong in /lib or /usr/lib.
> 
> I disagree with this based on understanding how the config system in
> these packages works. Also, I don't think a distro should do this type of
> patching if the patches are not accepted upstream.

Digressing a little myself, but trying to remain on point, the _only_ reason
I went with a split-/usr setup many years ago is because, back in the early
2000's, BOTH Debian's Security Handbook AND Gentoo's Security Handbook
recommended it as an option to enhance system security should all your other
defenses get compromised and an attacker gets onto the filesystem.  Does it
completely and utterly stop all lateral movement?  Nope.  Probably takes a
seasoned attacker all of 2-3mins to get around it.

That setup has run great for years.  I rarely re-install entire OSes, too,
preferring to maintain and upgrade them.  I.e., one of my Windows installs
is over five years old, having started w/ Vista SP1 and now it's on Win7
SP1.  Most people reinstall Windows twice a year because it can become
cluttered up so quickly.

So when that Freedesktop.org page came out a few years ago and suddenly
declared that split-/usr was broken, I just felt snubbed by it.  I had
7-year old installs that booted just fine.  Who were these freedesktop.org
people that were dictating that my particular setup was suddenly broken?
Call it a case of having my "geek pride" insulted.  Like hell I was going to
change.

But, you know, in reality, they had a point.  Original System V UNIX did a
lot of weird things that probably made sense decades ago, but don't now.
You find this virtually endemic across a lot of OSes, too:

  - Windows is happy to let you dribble non-OS related files all over C:
(which makes backups and OS re-installs a lot of fun) -- this was fine in
Win95/Win98, but became more of an issue in XP and up.  Nowadays, people
usually install the OS to C: and put games/programs on a separate drive
entirely.

  - NetWare seems to roll dice when installing things into the SYS: volume.
 Some configs are in SYS:\SYSTEM\ETC, Apache lives in SYS:\APACHE2\, and a
lot of other bits are encoded into eDirectory attributes (DNS/DHCP configs).

  - The *BSDs make heavy use of /usr/local for things that can confuse
non-BSD users (at first).  Even the install locations of Ports varies across
the BSDs (FBSD has /usr/ports, DF/BSD has /usr/dports, NBSD has pkgsrc, etc).



Anyways, back on point, FHS is more-or-less deprecated.  It was reasonable
when Linux had a small ecosystem.  Now, Linux has a *huge* ecosystem that it
operates in.  Everything from small, embedded devices to multi-node
supercomputing clusters, to servers and desktops.  FHS does doesn't scale
well to all of those configurations.  Android pretty much ignores FHS, from
what I can tell.

Options really are boiled down to these three:

1. Continue to support FHS as much as possible, including patching upstream
packages when they violate FHS.

2. Ignore FHS entirely and let upstream packages do what they want, within
reason (i.e., some patching may be needed depending on if one was running
Gentoo/Linux or Gentoo/FreeBSD).

3. Develop our own, Gentoo-specific variant of FHS that we use and which
suits the particulars of our distribution in a way that we feel is sensible
(my choice).  Packages are patched as appropriate, after discussion/debate.
 For all we know, the way an upstream package does something by default
might be worth integrating into our FHS design.

Further on point #3, we'd have to probably develop a high-level,
kernel-agnostic layout that can be modified by kernel-specific differences.
 I.e., Gentoo/Linux is going to do things one way while Gentoo/FreeBSD is
going to do it a different way.  Ditto for Hardened or Embedded stuff.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Samuli Suominen]

On 01/03/14 02:18, Alon Bar-Lev wrote:
> On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs <williamh@gentoo.org> wrote:
>> On Fri, Feb 28, 2014 at 09:57:15PM +0000, David Leverton wrote:
>>> William Hubbs wrote:
>>>> The reason the split happened is pretty straight forward, and every other
>>>> "justification" for continuing it was come up with after the fact.
>>> I keep hearing this, but I really don't see how it's relevant.  I'm sure
>>> you'll find lots of things in your life that you use for some purpose
>>> other than what they were originally invented for¹, and there's no
>>> reason why /usr should be any different.  All that matters is whether or
>>> not the newer reasons for having separate /usr actually provide a benefit.
>> And I would argue that the maintenance cost of having separate /usr in a
>> general sense is much higher than the benefit it provides.
>>
>> The problem with it is that it is next to impossible nowadays to define
>> what should go in / vs what should go in /usr.
>>
>> William
> Now it is difficult as too much time it was ignored.

Nod
If only Portage had supported checking if files from /usr were used by
files installed to /
Hard to create check for every case, but something like libraries and NEEDED
entries (bug 443590) would have been a start
But there simply wasn't enough popular demand for sep. /usr, so nobody
was willing to do the work

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

[Steven J. Long]

On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
> If only Portage had supported checking if files from /usr were used by
> files installed to /
> Hard to create check for every case, but something like libraries and NEEDED
> entries (bug 443590) would have been a start
> But there simply wasn't enough popular demand for sep. /usr, so nobody
> was willing to do the work

Actually when I proposed working on exactly that (twice), for both initramfs
and traditional usr setups, you and mgorny shouted me down, diverting it into
a discussion about how I was a "hater" for not seeing why I should change
anything on my systems.

That's why there was no demand: every halfway-sane proposal at collaboration
was turned into an insane argument. No-one with any self-respect would want
to collaborate with people who treat them like that. 

Neat bit of revisionism though; I almost thought you cared about us old
fusties for a moment there.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Samuli Suominen]

On 01/03/14 08:40, Steven J. Long wrote:
> On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
>> If only Portage had supported checking if files from /usr were used by
>> files installed to /
>> Hard to create check for every case, but something like libraries and NEEDED
>> entries (bug 443590) would have been a start
>> But there simply wasn't enough popular demand for sep. /usr, so nobody
>> was willing to do the work
> Actually when I proposed working on exactly that (twice), for both initramfs
> and traditional usr setups, you and mgorny shouted me down, diverting it into
> a discussion about how I was a "hater" for not seeing why I should change
> anything on my systems.

I don't remember anything of that sort. I may have overlooked at
your suggestion and replied to other part of your post, but I certainly
haven't said such checks would be a bad idea.
I don't appericiate the twisting of history.

> Neat bit of revisionism though; I almost thought you cared about us old
> fusties for a moment there.
>

I don't appericiate the attempt of trying to categorize me into one
of these pro-, anti-, {systemd,udev,eudev,sep. /usr,whatever} camps.
I wonder, did you notice who filed bug 443590 to begin with?

- Samuli

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

[Steven J. Long]

On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > But let's be real here: if I install something and
> > want to configure its system-wide bits, the first place I go is ALWAYS
> > /etc.  When I don't find it there, with the rest of the system config
> > files, my day gets a little worse and I lose a bit of time trying to
> > interrogate a search engine for the answer.  And that's annoying.
> > That sucks.
> 
> This hasn't changed.
> The configuration files these packages are putting in /lib are not
> meant to be edited; they are the package provided defaults. If you want
> to override one of them, you do that in a file with the same path and
> name in /etc, like I mentioned in another message in this thread.

The problem, as has been explained many many times, is that the rest
of the config is somewhere random on the system. But you knew that,
right? You were just telling a half-truth, effectively.

I for one prefer a distro to do a bit of work and make my life easier,
since it makes life easier for everyone who uses the distro. Why the
hell should I care if some bindist can't etc-update? WTF does that
have to do with Gentoo?

If I wanted a shitty distro that didn't bother to do anything at
all, I'd use LFS. At least they don't pretend, then fall over themselves
to do a crap load of work rather than admit a mistake; that hey, y'know
what? Some of those things from 30 years ago were a damn good idea,
and maybe just maybe, they worked some of these issues out back then,
so we could stand on their shoulders instead of digging through
their garbage.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Duncan]

Steven J. Long posted on Sat, 01 Mar 2014 06:48:54 +0000 as excerpted:

> I for one prefer a distro to do a bit of work and make my life easier,
> since it makes life easier for everyone who uses the distro. Why the
> hell should I care if some bindist can't etc-update? WTF does that have
> to do with Gentoo?

Because if they can't etc-update, they'll come up with some other 
solution that might not work so well for gentoo, and as upstream for some 
number of packages they'll propagate that solution, causing more trouble 
for gentoo trying to fix the impedance mismatch between their way and 
ours.

Which is basically where we're at.  Upstream came up with this /etc/ 
config modifying a package-specific default config somewhere else random 
on the system idea because they didn't have a good etc-update, and now we 
have to figure out the most sane way to try to integrate that with 
gentoo's etc-update based system.  If we'd have been able to propagate 
etc-update or similar before they came up with their solution, we'd not 
have this problem, but of course that's a historical if that we can't go 
back and revisit... except in possibly trying to get something like etc-
update propagated now to reduce similar problems in the future.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

On Sat, Mar 01, 2014 at 06:48:54AM +0000, Steven J. Long wrote:
> On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > > But let's be real here: if I install something and
> > > want to configure its system-wide bits, the first place I go is ALWAYS
> > > /etc.  When I don't find it there, with the rest of the system config
> > > files, my day gets a little worse and I lose a bit of time trying to
> > > interrogate a search engine for the answer.  And that's annoying.
> > > That sucks.
> > 
> > This hasn't changed.
> > The configuration files these packages are putting in /lib are not
> > meant to be edited; they are the package provided defaults. If you want
> > to override one of them, you do that in a file with the same path and
> > name in /etc, like I mentioned in another message in this thread.
> 
> The problem, as has been explained many many times, is that the rest
> of the config is somewhere random on the system. But you knew that,
> right? You were just telling a half-truth, effectively.

No sir, I was not telling a half-truth.

If the default configuration is stored in /lib/udev/rules.d for example,
and you can override that default by dropping files of the same name in
/etc/udev/rules.d, I don't see what the concern is.

> I for one prefer a distro to do a bit of work and make my life easier,
> since it makes life easier for everyone who uses the distro. Why the
> hell should I care if some bindist can't etc-update? WTF does that
> have to do with Gentoo?

With this method, you don't need to etc-update, so I would say that in a
way this is easier. Your system-admin-provided files in /etc are not
owned by the packages, just the files in /lib are.

> If I wanted a shitty distro that didn't bother to do anything at
> all, I'd use LFS. At least they don't pretend, then fall over themselves
> to do a crap load of work rather than admit a mistake; that hey, y'know
> what? Some of those things from 30 years ago were a damn good idea,
> and maybe just maybe, they worked some of these issues out back then,
> so we could stand on their shoulders instead of digging through
> their garbage.
 
 I'm not totally against keeping things from the past. It is just a case
 of evaluating those things and seeing whether they are still relevant.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Gilles Dartiguelongue]

Le samedi 01 mars 2014 à 10:06 -0600, William Hubbs a écrit :
> On Sat, Mar 01, 2014 at 06:48:54AM +0000, Steven J. Long wrote:
> > On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> > > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > > > But let's be real here: if I install something and
> > > > want to configure its system-wide bits, the first place I go is ALWAYS
> > > > /etc.  When I don't find it there, with the rest of the system config
> > > > files, my day gets a little worse and I lose a bit of time trying to
> > > > interrogate a search engine for the answer.  And that's annoying.
> > > > That sucks.
> > > 
> > > This hasn't changed.
> > > The configuration files these packages are putting in /lib are not
> > > meant to be edited; they are the package provided defaults. If you want
> > > to override one of them, you do that in a file with the same path and
> > > name in /etc, like I mentioned in another message in this thread.
> > 
> > The problem, as has been explained many many times, is that the rest
> > of the config is somewhere random on the system. But you knew that,
> > right? You were just telling a half-truth, effectively.
> 
> No sir, I was not telling a half-truth.
> 
> If the default configuration is stored in /lib/udev/rules.d for example,
> and you can override that default by dropping files of the same name in
> /etc/udev/rules.d, I don't see what the concern is.
> 
> > I for one prefer a distro to do a bit of work and make my life easier,
> > since it makes life easier for everyone who uses the distro. Why the
> > hell should I care if some bindist can't etc-update? WTF does that
> > have to do with Gentoo?
> 
> With this method, you don't need to etc-update, so I would say that in a
> way this is easier. Your system-admin-provided files in /etc are not
> owned by the packages, just the files in /lib are.
> 
> > If I wanted a shitty distro that didn't bother to do anything at
> > all, I'd use LFS. At least they don't pretend, then fall over themselves
> > to do a crap load of work rather than admit a mistake; that hey, y'know
> > what? Some of those things from 30 years ago were a damn good idea,
> > and maybe just maybe, they worked some of these issues out back then,
> > so we could stand on their shoulders instead of digging through
> > their garbage.
>  
>  I'm not totally against keeping things from the past. It is just a case
>  of evaluating those things and seeing whether they are still relevant.

I think the biggest issue here is that if the filename changes or the
setting that is overridden changes, then end-user or sysadmin is the one
that will suffer from settings not being applied and not knowing why.

This already happened with systemd/udev and net rules for example and I
am pretty sure in a couple of other packages but I have no other
examples on the top of my head.

Sure at some point you have to make things evolve but this upstream
solution simply isn't nice for its users.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3448 bytes --]

On Sat, Mar 1, 2014 at 8:06 AM, William Hubbs <williamh@gentoo.org> wrote:

> On Sat, Mar 01, 2014 at 06:48:54AM +0000, Steven J. Long wrote:
> > On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> > > On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > > > But let's be real here: if I install something and
> > > > want to configure its system-wide bits, the first place I go is
> ALWAYS
> > > > /etc.  When I don't find it there, with the rest of the system config
> > > > files, my day gets a little worse and I lose a bit of time trying to
> > > > interrogate a search engine for the answer.  And that's annoying.
> > > > That sucks.
> > >
> > > This hasn't changed.
> > > The configuration files these packages are putting in /lib are not
> > > meant to be edited; they are the package provided defaults. If you want
> > > to override one of them, you do that in a file with the same path and
> > > name in /etc, like I mentioned in another message in this thread.
> >
> > The problem, as has been explained many many times, is that the rest
> > of the config is somewhere random on the system. But you knew that,
> > right? You were just telling a half-truth, effectively.
>
> No sir, I was not telling a half-truth.
>
> If the default configuration is stored in /lib/udev/rules.d for example,
> and you can override that default by dropping files of the same name in
> /etc/udev/rules.d, I don't see what the concern is.
>
>
My understanding of his point was that right now configs are stored in one
file or in one directory.

/etc/default/foo perhaps or /etc/foo.d/{a,b,c}

it is easy for a some users to determine, using existing tools (vim, less,
etc.) to view what the configuration state is.

When the default configs are in /lib/udev/.../ and the over-rides are in
/etc/udev/.../ that is perhaps less clear. Many applications already
provide app specific tools for this. You can run apt-config dump to dump
your entire apt configuration (on debian / ubuntu) for example. I'm unsure
if polkit or dbus have a tool that will read in the configuration and dump
what the daemon thinks the state would be (if it loaded it.) (puppet has

I think part of the oddity of this objection is that this move is years old
already.

gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
solution somewhat elegant from my side as a sysadmin.

-A


> > I for one prefer a distro to do a bit of work and make my life easier,
> > since it makes life easier for everyone who uses the distro. Why the
> > hell should I care if some bindist can't etc-update? WTF does that
> > have to do with Gentoo?
>

> With this method, you don't need to etc-update, so I would say that in a
> way this is easier. Your system-admin-provided files in /etc are not
> owned by the packages, just the files in /lib are.
>
> > If I wanted a shitty distro that didn't bother to do anything at
> > all, I'd use LFS. At least they don't pretend, then fall over themselves
> > to do a crap load of work rather than admit a mistake; that hey, y'know
> > what? Some of those things from 30 years ago were a damn good idea,
> > and maybe just maybe, they worked some of these issues out back then,
> > so we could stand on their shoulders instead of digging through
> > their garbage.
>
>  I'm not totally against keeping things from the past. It is just a case
>  of evaluating those things and seeing whether they are still relevant.
>
>

[-- Attachment #2: Type: text/html, Size: 4596 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3033 bytes --]

Dnia 2014-02-28, o godz. 15:59:35
hasufell <hasufell@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Samuli Suominen:
> > 
> > On 28/02/14 13:15, Patrick Lauer wrote:
> >> On 02/27/2014 09:08 PM, Anthony G. Basile wrote:
> >>> Hi everyone,
> >>> 
> >>> I'm putting the call out there for any agenda items for the
> >>> next Council meeting, which will be held on March 11, 2014 at
> >>> 1900 UTC.  This is short notice but we got off track because of
> >>> FOSDEM and we're going to try to get back on track.
> >>> 
> >>> So far, the only item is final ratification of glep 63 [1].
> >> Since it's still a bit cold I'd like to start a nice fire to warm
> >> us up:
> >> 
> >> I'd like QA and Council to figure out how much we care about
> >> FHS.
> >> 
> >> My main complaint is some projects (including e.g. systemd and 
> >> apparently now also udev) storing config files in /lib and/or
> >> /usr/lib.
> >> 
> >> From FHS' point of view this is totally wrong, config files go to
> >> /etc Only libraries should be in /lib.
> > 
> > Wow. What about libtool .la text files? What about kernel modules? 
> > What about the genereted modules.* data in /lib/modules/$version/
> > which are used in early boot by eg. kmod-static-nodes? What about
> > the binaries of OpenRC in /lib/rc, they aren't libraries? And what
> > about vendor modprobe.d files in /lib/modprobe.d? I could continue
> > this all day. I'm just trying to point out "Only libraries should
> > be in /lib." is complete bs and does not work. Does FHS really
> > articulate it the way you said it, "Only libraries should be in
> > /lib." or was that your own interpretation of it?
> > 
> > I'm not really expecting an answer as I'm already convinced FHS is
> > so badly outdated it's sad it doesn't suit modern systems. I hope
> > they will catch up at some point.
> > 
> > - Samuli
> > 
> 
> In addition to the questions of Samuli...
> 
> What about python, perl, ruby and whatnot script languages.
> What about haskell and pascal? Some of them files are reported to be
> "data" files.
> What about erlangs .erl and .hrl (text)?
> What about mono/C# .exe and .dll (are they architecture-dependant or
> can I treat them as "data files" and move them to "/usr/share/"?)
> What about non-trivial packages like fpc, firefox, portage and
> libreoffice that all violate FHS? Who will fix it and maintain that
> stuff downstream?
> What about /opt, we don't follow that either?
> 
> What about /usr/include and ".hpp" files (only C is valid according to
> FHS)? Who will fix boost?
> 
> I skip the part of running some funny "find" commands on my local system.

Please ping me if this thread brings something constructive or
decisive. I don't have time to read all the trolling and useless
whining, yet I don't want to miss if somewhere in the middle
of this crap QA or someone decides to apply a policy that will affect
me. Thanks.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

[Peter Stuge]

Everyone on this list really except perhaps Duncan really needs to
learn to trim quotess. Kthx.

Gilles Dartiguelongue wrote:
> Sure at some point you have to make things evolve but this upstream
> solution simply isn't nice for its users.

That may be, but I don't think it's a distribution's responsibility
to try to own that problem.


//Peter

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

On Sun, Mar 02, 2014 at 05:49:59PM +0100, Peter Stuge wrote:
> Gilles Dartiguelongue wrote:
> > Sure at some point you have to make things evolve but this upstream
> > solution simply isn't nice for its users.
> 
> That may be, but I don't think it's a distribution's responsibility
> to try to own that problem.

This is my point exactly. Patrick's proposal is that we make this policy
that all config files belong in /etc a distro policy, including
patching upstream software to force it to conform. If we make this a
distro policy and upstream rejects it, there will always be a lot of
work downstream that is imo unnecessary.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Rich Freeman]

On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <antarus@gentoo.org> wrote:
>
> gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> solution somewhat elegant from my side as a sysadmin.
>

I think the "right approach" depends on the degree to which the file
requires tweaking.

For 99% of users, udev requires no touching at all (though the
persistent network names drive me nuts so I touch it anyway).  If you
do touch it most likely you're just adding one rule, or overriding a
rule or two.  That makes the approach it uses of defaults and
overrides really nice, because you don't have a ton of cruft to merge
in /etc - the only code that is present is the stuff that matters.

For 99% of users, xorg.conf needs little touching at all (which is a
VERY welcome change from how it used to be).  My xorg.conf.d contains
one file with 6 lines in it.  So, the new approach makes sense.

My postfix config contains a large number of overrides, as do most.
Postfix really needs a moderate bit of setup in terms of setting
domains, policies, and so on.  Most people have anti-spam or
greylisting or such enabled, or they relay through an outside smtp
server, and so on.  Plug-and-play configs are unusual for a mail
server.  That tends to make the big file in /etc with lots of changes
more useful - it gives you a template to edit, and if upstream changes
something you want to see what it is so that you can decide how to
best merge in your tweaks.

So, the traditional approach works best for config files that need a
lot of editing which don't lend themselves to modularization.  I find
the new approach works better for situations where the files are very
modular (that is, in practice you can change just one setting and not
have to look at others), and when changes are the exception rather
than the rule (which means that you're only managing exceptions).

Personally, I'm glad my udev rules directory is now nearly empty.
Previously it was just a situation where orphan rules caused trouble,
updates required care, and so on.  Now the only things that can
possibly cause trouble are my disabling of the persistent network
names, and a few rules that add symlinks for some pl2303s so that I
can refer to them with consistent names (which I don't actually need
any longer anyway now that I use a cablecard tuner).

Rich

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

[Wyatt Epp]

On Sat, Mar 1, 2014 at 11:06 AM, William Hubbs <williamh@gentoo.org> wrote:
>
> No sir, I was not telling a half-truth.
>
> If the default configuration is stored in /lib/udev/rules.d for example,
> and you can override that default by dropping files of the same name in
> /etc/udev/rules.d, I don't see what the concern is.
>
Oh, that's easy.  The concern is that, as a sysadmin, I have no idea
what the current configuration even is, let alone any idea that the
override is even possible or how the override file is formatted.  This
problem is magnified for every thing that works this way multiplied
again by every instance that the configuration needs to be checked or
changed (because it likely needs to be looked up again because it's in
a non-standard place and we humans don't remember things well if
they're not a constant presence in our lives).

In short: Making life easier for users is why distros even exist in
the first place.  This method lacks transparency and makes life harder
for users.

On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <antarus@gentoo.org> wrote:
>
> it is easy for a some users to determine, using existing tools (vim, less,
> etc.) to view what the configuration state is.
>
This point is incredibly important:  It should really never require a
search engine to even determine what the current config looks like.  I
don't care if it involves moving the canonical config, or putting a
stub config in /etc with a comment to the effect of:
# This file is for overrides; please see /lib/foo/bar for the default
system configuration.

...or throwing a bunch of code at it to invent a better config
tracking tool (again), or whatever.

Or say "screw it" and this thread dies with no tangible action like so
many others; enjoy your papercuts, users.

> When the default configs are in /lib/udev/.../ and the over-rides are in
> /etc/udev/.../ that is perhaps less clear. Many applications already provide
> app specific tools for this. You can run apt-config dump to dump your entire
> apt configuration (on debian / ubuntu) for example. I'm unsure if polkit or
> dbus have a tool that will read in the configuration and dump what the
> daemon thinks the state would be (if it loaded it.) (puppet has
>
Oh PLEASE don't let this become a trend.  I can't fathom any
legitimate reason to reinvent cat repeatedly.

> gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> solution somewhat elegant from my side as a sysadmin.
>
I'm curious: how many people have you encountered who even know those
can be configured?  (Never mind things like "how does this work?" or
"what does this even do?"; you've made a very nice list of things
hardly anyone understands. :/ )

Cheers,
Wyatt

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

[Samuli Suominen]

On 02/03/14 19:51, William Hubbs wrote:
> On Sun, Mar 02, 2014 at 05:49:59PM +0100, Peter Stuge wrote:
>> Gilles Dartiguelongue wrote:
>>> Sure at some point you have to make things evolve but this upstream
>>> solution simply isn't nice for its users.
>> That may be, but I don't think it's a distribution's responsibility
>> to try to own that problem.
> This is my point exactly. Patrick's proposal is that we make this policy
> that all config files belong in /etc a distro policy, including
> patching upstream software to force it to conform. If we make this a
> distro policy and upstream rejects it, there will always be a lot of
> work downstream that is imo unnecessary.
>
> William
>

Right, the only relavent fact here is that /usr and likeminded
directories like /lib can be mounted RO and everything will
still work.
Likewise anything in /usr, /lib, /bin, /sbin, and co. should be
for static files, such as for configuration templates which
remain modified only by the package manager.
And the udev rules don't violate any of that, which makes
it perfectly working design, which makes the whole usage
of such configuration setup by upstreams so common.

So the proposal that every config should go to /etc must
be somekind of joke. No offense to anyone ;)

- Samuli

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3373 bytes --]

On Mon, Mar 3, 2014 at 12:35 AM, Wyatt Epp <wyatt.epp@gmail.com> wrote:

> On Sat, Mar 1, 2014 at 11:06 AM, William Hubbs <williamh@gentoo.org>
> wrote:
> >
> > No sir, I was not telling a half-truth.
> >
> > If the default configuration is stored in /lib/udev/rules.d for example,
> > and you can override that default by dropping files of the same name in
> > /etc/udev/rules.d, I don't see what the concern is.
> >
> Oh, that's easy.  The concern is that, as a sysadmin, I have no idea
> what the current configuration even is, let alone any idea that the
> override is even possible or how the override file is formatted.  This
> problem is magnified for every thing that works this way multiplied
> again by every instance that the configuration needs to be checked or
> changed (because it likely needs to be looked up again because it's in
> a non-standard place and we humans don't remember things well if
> they're not a constant presence in our lives).
>
> In short: Making life easier for users is why distros even exist in
> the first place.  This method lacks transparency and makes life harder
> for users.
>

I think this is a reasonable thing to ask for, I just doubt anyone will
volunteer to implement it.


>
> On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner <antarus@gentoo.org> wrote:
> >
> > it is easy for a some users to determine, using existing tools (vim,
> less,
> > etc.) to view what the configuration state is.
> >
> This point is incredibly important:  It should really never require a
> search engine to even determine what the current config looks like.  I
> don't care if it involves moving the canonical config, or putting a
> stub config in /etc with a comment to the effect of:
> # This file is for overrides; please see /lib/foo/bar for the default
> system configuration.
>
> ...or throwing a bunch of code at it to invent a better config
> tracking tool (again), or whatever.
>
> Or say "screw it" and this thread dies with no tangible action like so
> many others; enjoy your papercuts, users.
>
> > When the default configs are in /lib/udev/.../ and the over-rides are in
> > /etc/udev/.../ that is perhaps less clear. Many applications already
> provide
> > app specific tools for this. You can run apt-config dump to dump your
> entire
> > apt configuration (on debian / ubuntu) for example. I'm unsure if polkit
> or
> > dbus have a tool that will read in the configuration and dump what the
> > daemon thinks the state would be (if it loaded it.) (puppet has
> >
> Oh PLEASE don't let this become a trend.  I can't fathom any
> legitimate reason to reinvent cat repeatedly.
>


Many of the config files are large, and splitting them into segments makes
it easier to read.


> > gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
> > solution somewhat elegant from my side as a sysadmin.
> >
> I'm curious: how many people have you encountered who even know those
> can be configured?  (Never mind things like "how does this work?" or
> "what does this even do?"; you've made a very nice list of things
> hardly anyone understands. :/ )
>

I configure dbus and polkit on a regular basis...but I also managed a very
large fleet of desktops, and very few servers. Pretty much the exact
opposite of most Gentoo developers I think, which is why I have the
opposite opinion of many of them.

>
> Cheers,
> Wyatt
>
>

[-- Attachment #2: Type: text/html, Size: 4654 bytes --]

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

[Wyatt Epp]

On Mon, Mar 3, 2014 at 11:10 AM, Alec Warner <antarus@gentoo.org> wrote:
>
> Many of the config files are large, and splitting them into segments makes
> it easier to read.
>
Ah, no, impedance mismatch. Split configs are easy-- /etc/env.d/ took
something like two minutes to grasp years ago.

To clarify, I was more dismayed by the whole "If you want to know the
configuration run this purpose-built utility that ends up spitting out
a bunch of text anyway rather than just looking at the files" part.

If the _only_ way to get the config for something is ever to run a
specific command specifically tailored for that purpose, then it's
evidence of a truly shocking and advanced sadism (not to mention a
complete and utter failure of software engineering as a discipline).

Cheers,
Wyatt

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

[Rich Freeman]

On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp <wyatt.epp@gmail.com> wrote:
> If the _only_ way to get the config for something is ever to run a
> specific command specifically tailored for that purpose, then it's
> evidence of a truly shocking and advanced sadism (not to mention a
> complete and utter failure of software engineering as a discipline).

I understand what you're saying, but keep in mind that default
configuration is often determined first and foremost by code.

If everything is right any hard-coded defaults get incorporated into
config file templates.  However, if a config item is commented out,
there is no actual guarantee that what the system actually does is
what is indicated in the commented instructions.

That is part of why tools usually exist for dumping the REAL config.
In the end that is the only way you can be really sure what the
software is actually doing, between overrides, defaults, incorrect
comments, and so on.

As I've already commented, I find the most useful approach varies
depending on how much these files need to be tweaked.  In theory I
could write my own set of udev rules, but in reality few do that.  If
the sourcing of subdirs/vhosts/etc is set up in a clever way for
apache you can minimize the need to heavily edit a monolithic config
file.

So a lot of this comes down to the particular application and how
clever we are with how it is configured, and how much it needs to be
configured.  It also comes down to how much upstream has already
thought through these problems and presented an elegant solution...

Rich

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

[Samuli Suominen]

On 03/03/14 23:13, Rich Freeman wrote:
> On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp <wyatt.epp@gmail.com> wrote:
>> If the _only_ way to get the config for something is ever to run a
>> specific command specifically tailored for that purpose, then it's
>> evidence of a truly shocking and advanced sadism (not to mention a
>> complete and utter failure of software engineering as a discipline).
> I understand what you're saying, but keep in mind that default
> configuration is often determined first and foremost by code.

Which is why should shouldn't be calling the files in eg. /lib/udev/rules.d
configs, but rather defaults which are unrolled from the applications
code.
Far better to have the defaults unrolled into whatever formatted file
than have it built-in hidden in the applications code.
Thus, doesn't matter if it's XML or JavaScript or whatever, all those
files belong to /lib just fine if needed in early boot, long as they are
defaults that are read-only, not the actual configs, which are by
definition not read-only.
I'm not saying you, but in general, including in this thread, there
seems to be some people actually agreeing but not knowing about
it when another is speaking of configs and another is referring
them as something else.

>
> If everything is right any hard-coded defaults get incorporated into
> config file templates.  However, if a config item is commented out,
> there is no actual guarantee that what the system actually does is
> what is indicated in the commented instructions.
>
> That is part of why tools usually exist for dumping the REAL config.
> In the end that is the only way you can be really sure what the
> software is actually doing, between overrides, defaults, incorrect
> comments, and so on.
>
> As I've already commented, I find the most useful approach varies
> depending on how much these files need to be tweaked.  In theory I
> could write my own set of udev rules, but in reality few do that.  If
> the sourcing of subdirs/vhosts/etc is set up in a clever way for
> apache you can minimize the need to heavily edit a monolithic config
> file.
>
> So a lot of this comes down to the particular application and how
> clever we are with how it is configured, and how much it needs to be
> configured.  It also comes down to how much upstream has already
> thought through these problems and presented an elegant solution...
>
>

Nod.