Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On 03/03/14 23:13, Rich Freeman wrote: > On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp 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.
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Mon, Mar 3, 2014 at 3:16 PM, Wyatt Epp 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)
On Mon, Mar 3, 2014 at 11:10 AM, Alec Warner 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)
On Mon, Mar 3, 2014 at 12:35 AM, Wyatt Epp wrote: > On Sat, Mar 1, 2014 at 11:06 AM, William Hubbs > 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 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 > >
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
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)
On Sat, Mar 1, 2014 at 11:06 AM, William Hubbs 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 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)
On Sat, Mar 1, 2014 at 1:31 PM, Alec Warner 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)
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 signature.asc Description: Digital signature
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
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)
On Sat, Mar 1, 2014 at 8:06 AM, William Hubbs wrote:
> On Sat, Mar 01, 2014 at 06:48:54AM +, 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.
>
>
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Le samedi 01 mars 2014 à 10:06 -0600, William Hubbs a écrit : > On Sat, Mar 01, 2014 at 06:48:54AM +, 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 Gentoo
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 01, 2014 at 06:48:54AM +, 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. signature.asc Description: Digital signature
[gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Steven J. Long posted on Sat, 01 Mar 2014 06:48:54 + 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)
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)
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)
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 ;-)
