| 1 |
On 28/02/14 17:34, Anthony G. Basile wrote: |
| 2 |
> On 02/28/2014 06:15 AM, Patrick Lauer wrote: |
| 3 |
>> On 02/27/2014 09:08 PM, Anthony G. Basile wrote: |
| 4 |
>>> Hi everyone, |
| 5 |
>>> |
| 6 |
>>> I'm putting the call out there for any agenda items for the next |
| 7 |
>>> Council |
| 8 |
>>> meeting, which will be held on March 11, 2014 at 1900 UTC. This is |
| 9 |
>>> short notice but we got off track because of FOSDEM and we're going to |
| 10 |
>>> try to get back on track. |
| 11 |
>>> |
| 12 |
>>> So far, the only item is final ratification of glep 63 [1]. |
| 13 |
>> Since it's still a bit cold I'd like to start a nice fire to warm us up: |
| 14 |
>> |
| 15 |
>> I'd like QA and Council to figure out how much we care about FHS. |
| 16 |
>> |
| 17 |
>> My main complaint is some projects (including e.g. systemd and |
| 18 |
>> apparently now also udev) storing config files in /lib and/or /usr/lib. |
| 19 |
>> |
| 20 |
>> From FHS' point of view this is totally wrong, config files go to /etc |
| 21 |
>> Only libraries should be in /lib. |
| 22 |
>> Moving things to /usr/lib adds the extra fun that /usr needs to be |
| 23 |
>> mounted to acces *config files*. This is bad for our collective blood |
| 24 |
>> pressure. |
| 25 |
>> |
| 26 |
>> So I'd like to see config files stored in /etc again. Where they can be |
| 27 |
>> properly tracked and versioned ... |
| 28 |
>> |
| 29 |
>> (iow, storing config files in any other location than /etc is wrong; |
| 30 |
>> storing example configs in e.g. /usr/share is fine too; storing config |
| 31 |
>> in any other place is a valid bug that needs to be fixed) |
| 32 |
>> |
| 33 |
>> For upstreams that insist on splitting configs in "system default" and |
| 34 |
>> "local override" (which is rather nonsensical, but let them have some |
| 35 |
>> fun) I would suggest a subfolder of /etc, maybe /etc/defaults or |
| 36 |
>> /etc/systemdefaults or maybe /etc/lib/etc/usr/static if that's what |
| 37 |
>> makes people happy |
| 38 |
>> |
| 39 |
>> |
| 40 |
>> Enjoy the exothermic oxidation, |
| 41 |
>> |
| 42 |
>> Patrick |
| 43 |
>> |
| 44 |
>> |
| 45 |
> Speaking as a council member and the next chair: Patrick, how would |
| 46 |
> you pose this as a motion? As stated, the council should "discuss |
| 47 |
> FHS" but how would you word this as a policy that we can rule on? I |
| 48 |
> have an idea but would like to hear what you want. |
| 49 |
> |
| 50 |
> Speaking as a gentoo dev: This is one of my objections with systemd |
| 51 |
> and the whole / + /usr merge. It violates a standard which is assumed |
| 52 |
> in many setups, namely FHS. Another is that systemd violates the "one |
| 53 |
> thing well" principle. |
| 54 |
> |
| 55 |
|
| 56 |
That isn't true; systemd has dozens of sep. executables and each of them |
| 57 |
do one'ish task, and do it well. The one running in PID 1 has very |
| 58 |
little to do with them. |
| 59 |
So by your definition, it completely follows the "one thing well" principle. |
| 60 |
Futher, 'assumed in many setups', / + /usr, from which hat you pulled |
| 61 |
that rabbit out of? Merging the directories would propably bring in |
| 62 |
better compability, as |
| 63 |
it wouldnt matter anymore if something is hardcoding /bin/foo or |
| 64 |
/usr/bin/foo or even /usr/sbin/foo. |
| 65 |
|
| 66 |
I'd like the council to stick to facts when discussing the topic, |
| 67 |
please. And remember, I'm not anykind of pro-systemd advocate, AT ALL. |
| 68 |
|
| 69 |
And sorry for jumping in on the thread, but I couldn't help it, when |
| 70 |
people spread these things. |
Archives