shared /boot support. bz 197065

[Dave Jones]

On Mon, Mar 24, 2008 at 03:36:49PM -0700, Roland McGrath wrote:
 > I will probably continue to find it desireable to make a dozen different
 > 100-200M partitions to use as /boot for installs, so I don't really care
 > about the name noncollision.  But it sure would make it a little simpler
 > to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
 > I'm always doing.
 > 
 > I didn't really review the spec bits thoroughly.  But as far as spec
 > magic and building goes, I think it should be fine if you just get every
 > %{KVERREL}%{suffix} and make it %{KVERREL}%{suffix}.%{_arch}.
 > Except I think you mean %{_target_cpu}, not %{_arch}.
 > 
 > I agree with Jarod that keeping .%{_arch} always immediately after 
 > %{KVERREL}%{suffix} is best.  For most things, it just becomes part
 > of the whole "kernel release string" wad.
 > 
 > As has been noted, a lot of things will get unhappy if they cannot
 > use foo-`uname -r` and /lib/modules/`uname -r` as file names for
 > the installed bits.  I can speak for systemtap/elfutils, which has
 > no plan other than /lib/modules/`uname -r` for where to locate the
 > kernel and module binaries (or user manual intervention with a switch).
 > 
 > Even if it were not for the trouble with finding all the hidden
 > dependencies on that, tools needing to be compatible across
 > kernel/distro versions, etc., where would those tools get the
 > %{_arch} value to look for?  uname -m?  uname -i?  I don't think
 > either of those gets i586 when that's the kernel rpm %{_arch} and
 > the CPU is an i686, for example.
 > 
 > All this suggests to me that the only thing we really can make fly is to
 > include the differentiator in EXTRAVERSION.  It will be noticeable to
 > users and probably draw a lot of questions and look redundant in many
 > places that display the arch too.  But it would not be any new can of
 > worms on technical grounds.  
 > 
 > For just 32/64 sharing and not e.g. i586/i686 sharing (both kernels of
 > same version selectable for the same install), it could be made less
 > repetitious by not using .%{_target_cpu} but instead just %(L=%{_lib#lib};
 > test -z "$L" || echo ".$L"), i.e. ".64" or nothing.  (And that would be no
 > suffix on ia64 et al where lib64 is not used, as well as the 32-bit cases.)

As the number of things that look for vmlinuz scrolled up the screen,
I lost more and more interest in pursueing this.  The amount of churn
we'd have to do to various packages doesn't really pay off vs the number
of people who ask for this. (I think this is literally the 3rd time I've
seen it requested in the 5 years I've been maintaining the kernel)

I'm leaning towards ->WONTFIX

	Dave

-- 
http://www.codemonkey.org.uk