[Mageia-dev] Please test: initscripts+systemd in updates_testing

[Thomas Backlund]

Colin Guthrie skrev 30.10.2011 13:26:
> 'Twas brillig, and Thomas Backlund at 29/10/11 21:13 did gyre and gimble:

>> So?
>> it's less impact on / than stuffing all of /usr on /
>
> I don't understand what point you're trying to make here. You'd be
> moving a whole bunch of stuff to /... And it becomes very tricky to
> administer exactly what to move to / as the dependencies are non-trivial
> to work out, the QA burden is very high to test all the various
> combinations of setups to ensure all the required bits have been moved to /
>
> After doing all that QA and ensuring all is well, then the whole
> separate of /usr and / is totally blurred anyway. As someone campaigning
> to keep /usr on a separate partition, I'd have thought this was what you
> were trying to protect against in the first place... it seems totally
> contradictory to suggest this as a solution.
>
> Keep in mind that one of the key aims in highlighting this issue via
> systemd is to actually ALLOW /usr to be a useful and self contained
> filesystem. If /usr is properly configured without leaking half of it to
> / it could be shared across multiple machines far more easily or even
> mounted as ro by default which could prove handy for security. Again,
> this is about highlighting the issues with an aim to making /usr much
> more useful. This is a laudable aim but you seem to be shooting it down
> due to gut reactions and prejudice. I've not yet seen any technical
> arguments from you about the topic.
>

I'm saying moving the stuff that is _really_ needed, not based on "udev 
might run"...

well, thinking some more on it I guess the real design flaw (not systemd 
specific) is using all of udev in init. Init should not care about more 
than getting disc access (and probably network for pxe  boots)

Then we wouldn't have to worry about "what udev might run" and could
keep a very clean /

>> Well, it _is_ idiotic if it breaks working setups / possibilities to
>> finetune systems.
>
> It depends on your definition of "working". Sure if you specifically
> work around the know limitations of the design then you may get a
> bootable system, which you could classify as working, but I wouldn't say
> this is a robust base. Just a house of cards waiting for the next
> failure. I'd rather try and address the problems properly and be frank
> about it in the discussions.
>

Well, it has worked 24/7 for servers for atleast last 15 years for
servers I maintain, so I'd say that is pretty robust.


--
Thomas