On Mon, Sep 30, 2013 at 11:37:53PM +0100, Neil Bothwick wrote: > On Mon, 30 Sep 2013 17:05:39 -0400, Walter Dnes wrote: > > > > If *something1* at boot time requires access to *something2* at boot > > > time that isn't available then I would say that *something1* is broken > > > by design not the *something2*. > > > > What about the case where *something2* *USED TO BE AVAILABLE, BUT HAS > > BEEN MOVED TO /USR* ? > > What about the case where something1 wasn't required at boot time but > changed circumstances mean it now is?
What about it? Honestly it's like you lot don't know the basics of scripting or something. $PATH ffs. (And don't start on at me about badly-coded apps: fix the apps, or the ebuilds not the OS: it's not broken, and certainly does not need to worked-around.) > > > So I would argue that devs relying on /usr always being there have > > > broken the "system". > > > > So I would argue that unnecessarily moving stuff into /usr is > > deliberate sabotage, designed to break *something1*. > > Define unnecessarily in that context? You can't, not for all use cases. > There are many files that clearly need to be available early on, and many > more that clearly do not. Between them is a huge grey area, files that > some need and some don't, that may be needed now or at some indeterminate > point in the future. If you put everything that may conceivably be needed > at early boot into /, you shift a large chunk of /usr/*bin/ and /usr/lib* > into /, effectively negating the point of a small, lean /. That puts us > right back where we started, try to define a point of separation that > cannot be defined. Funny, sounds a lot like deciding what to put in an initramfs. And frankly it's untrue[2]. Most of the core system utilities have long been intended to run people's systems. All you need to do is stop pretending "nu-skool" rubbish is as good as the stuff that's survived decades of use. By definition the latter is a much smaller pool of much higher-quality than the mountains of new unproven and untested stuff, that keeps falling over in real life. Exactly the same happened back then: we just don't see the admittedly smaller mountains of crap that fell by the wayside after a year or five. > initramfs is the new /, for varying values of new since most distros have > been doing it that way for well over a decade. Only it's not, since you're responsible for keeping it in sync with the main system. And for making sure it has everything you need. And hoping they don't change incompatibly between root and initramfs. The point is the burden has shifted, and made the distribution less of a distribution and more of a "DIY, and tough sh1t if it don't work, you get to pick up the pieces we broke" irrespective of how many scripts you provide to do work that was never needed before, and technically is not needed now[1] It will break. Everything does at some point or another. So I for one don't need the extra hassle from a totally unnecessary extra point of failure. Good luck to you if that's how you roll; just don't tell me what choices I should make, thanks. Regards, steveL. [1] http://forums.gentoo.org/viewtopic-t-901206.html [2] http://forums.gentoo.org/viewtopic-t-901206-start-75.html ..shows how few things you actually need to move. Note portage is fine with the directory symlinks from /usr to / (I checked with zmedico before I wrote it up.) Also the bug in lvm initscript got fixed, but I still much prefer my machine to have the few extra MB in rootfs, and be able to chuckle at all the eleventy-eleven FUD about those 2 directories. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
