Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Dnia 2014-02-28, o godz. 15:59:35 hasufell hasuf...@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 signature.asc Description: PGP signature
[gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
-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)
On Fri, Feb 28, 2014 at 10:59 AM, hasufell hasuf...@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)
On Fri, Feb 28, 2014 at 03:59:35PM +, 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/ signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
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)
On Fri, Feb 28, 2014 at 09:57:15PM +, 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 signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs willi...@gentoo.org wrote: On Fri, Feb 28, 2014 at 09:57:15PM +, 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)
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)
On Sat, Mar 01, 2014 at 12:24:02AM +, 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 signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs willi...@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)
On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: On Fri, Feb 28, 2014 at 7:47 PM, William Hubbs willi...@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 signature.asc Description: Digital signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 02/28/2014 7:47 PM, William Hubbs wrote: On Sat, Mar 01, 2014 at 12:24:02AM +, 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 ku...@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
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 01/03/14 02:18, Alon Bar-Lev wrote: On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs willi...@gentoo.org wrote: On Fri, Feb 28, 2014 at 09:57:15PM +, 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
