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.)
Thanks,
Roland
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
