On Wed, May 06, 2015 at 11:34:41AM +0200, Harald Hoyer wrote: > Meh, not in CC and not subscribed to kernel-list. Anyway... > > On 04.05.2015 19:57, Tom Callaway wrote: > > On 05/04/2015 01:49 PM, Josh Boyer wrote: > > > >> So if I understand the patch correctly, your usecase will still be > >> valid as the actual files are still in /boot. Nobody is expecting grub > >> (or whatever other loaded) to read files out of /usr/. > > > > Moving files in %posttrans to a different location seems like one heck of > > a hack. What problem are we trying to solve here with a "self-contained > > installation in /usr"? > > > > ~tom > > > > == Red Hat > > > > "heck of a hack"?? > We do a lot more for the kernel in postrans: > - depmod > - create the initrd and move it to /boot > - modify the bootloader conf (grubby) > > I don't see why additionally copying some files make it a "heck of a hack"? > > With "self-contained installation in /usr" we want to minimize the location > of distributed files, so we can have: > - stateless systems with a shared /usr gold master > - easy distribution of vendor supplied OS parts > - factory reset Hi, Not that my opinion matters much, but I think this is an interesting mind shift. The end result is the same as today, just extra files in /lib/modules/`uname -r`, right? This is one of those ideas, I am curious to see how it plays out. It can turn into nothing or allow us to do more interesting things from a package maintaince or sysadmin perspective. The only problem is how does one go about implementing ideas like this, aside from creating their own distro? If all we are doing is adding new files to /lib/modules, then it is low risk, I would think. But I would probably keep this in rawhide somehow (if at all possible). Then again I like some of the ideas of the stateless model as it makes updating machines (servers big and small) easier. I almost think Docker but with distros instead of apps. Just my 2cents. Cheers, Don _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel