[PATCH] kernel.spec: no more files in /boot

[Josh Boyer]

On Wed, May 06, 2015 at 10:29:36AM -0400, Don Zickus wrote:
> 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?

Actually, I was hoping some other kernel maintainers would chip in so
your opinion does matter.  I really don't want to change this in Fedora
to only have it reverted in a future RHEL.  Maybe Jarod or Rafael would
be kind enough to review as well...

And yes, your summary is correct.

> 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).

If we apply it, it would start in rawhide and work its way through the
normal Fedora release process.  So at this point the earliest release it
would land in would be Fedora 23.  The backwards compatibility Harald
noted was for ease of use in testing rawhide kernels on older userspace.

> 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.

Thanks.

josh