[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#561099: initramfs-tools: determination of "newest kernel" in update-initramfs -u uses improper sorting



Allow me this little statement since opening a new bug appears to be
fruitless.

> > Let me try:  "The program's behaviour differs from the description in
> > the manpage."  Doesn't sound like a bug to you?
> >
> > Of course, the issue can be fixed a) in the program or b) in the man
> > page, but in my opinion, it definitely should be fixed.
> >
> > Cheers!
> >
> > Thiemo

It has been a somewhat prolonged irritant for me, mainly due to lack of
time in tracking down each and every oddity that comes along. Testing
(squeeze) at some point put out a 2.6.32-trunk kernel that sorts after
any 2.6.32-n kernel and consequently always is the newest if it still is
around. Mind you, the user didn't build and install or even install
outside normal update procedures. Therefore, the point that these kernel
"tangents" are due to "expert-level" user actions is wrong in this case.
The argument that the onus is on the user may apply in unstable however
not for "testing" since that codename refers to testing the potential
release and not to testing the potential user. (Obciously, that argument
implies the naming problem "should" have been caught in unstable...oh well.)

Even so, the confusion caused by the unusually numbered kernel would
have been lessened considerably if the manpage had actually defined the
term "newest kernel" so that at least the user could understand what was
happening with the "update-initramfs -u" action. I might be overstepping
here but I would think that most people would consider the word "newest"
to refer to a temporal order and not a lexical. As it was with the
confusion of thinking that it should be updating the newest but for some
reason just isn't, I, and possibly others, had to go along behind
updates and redo that command with a -k option in order to get the
proper initrd.img updated, or find some other less tedious workaround.

In the end, I agree with Thiemo in that the manpage and the program's
behaviour are at odds.

regards,
-jeff


Reply to: