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

Sun Oct 30 13:19:23 CET 2011

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
+