Dnia 2014-02-28, o godz. 15:59:35
hasufell <[email protected]> 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: signature.asc
Description: PGP signature

Reply via email to