[rhelv6-beta-list] kernel-release now appends the arch

Stephan Wiesand stephan.wiesand at desy.de
Fri Apr 30 18:12:04 UTC 2010


On Apr 29, 2010, at 21:10 , inode0 wrote:

> On Thu, Apr 29, 2010 at 1:45 PM, Stephan Wiesand
> <stephan.wiesand at desy.de> wrote:
>> On Apr 29, 2010, at 14:58 , Jonathan S Billings wrote:
>>> On 04/28/2010 08:24 PM, Ned Slider wrote:
>>>> Indeed, it is not difficult to work around the issue, but why the change
>>>> in behaviour, and if it's intentional is it documented?
>>> 
>>> It's something that's been around in Fedora since Fedora 9 I believe, and looks like it's in
>>> RHEL6 now.  I believe this is the BZ issue that addresses the reason:
>>> 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=197065
>> 
>> So... we're all in for going through our scripts & specs with a fine comb because someone
>> wanted to install 32-bit & 64-bit FC5 on a common /boot partition in 2006?! Bill, Steve and
>> Larry will be delighted to hear that.
> 
> What sort of use in a script is breaking? Why would it matter if the
> kernel-release was renamed to whatever as long as that is the name of
> the kernel release?
> 
> I'm sympathetic to not liking changes that affect scripts and have
> been bitten by changes in RHEL in the past but I don't really see a
> use case where `uname -r` isn't still going to return the right
> thing?! Maybe I'm not being imaginative enough.

well, imagine an environment where external kernel modules are a necessity. Ok, they almost never really are, because almost always we could tell our users to get lost and use an OS that works for them. But, even setting aside the very few real cases where this actually isn't an option, I don't like the idea.

So, please try to imagine you'd been maintaining a script that cares for updates of kernels *and* additional modules, making sure that each and every system that boots either comes up with the current kernel and all required modules available (Fedora/RHEL has *no* tool helping here - please prove me wrong) or the last kernel for which this was possible and signal the error, since the RHEL3 times, going through some quite significant changes along the way with no chance to drop support for the old stuff. Next, imagine they're throwing this fairly arbitrary change at you - and for what reason.

I'm not so much questioning the change itself - yes, I can cope, even though it's going to make things even more awkward than they already are, and the effort is not neglibile - as the reason presented. What I've read so far does not warrant *any* change whatsoever in an "enterprise" distribution. IMHO.

- Stephan

-- 
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany





More information about the rhelv6-beta-list mailing list