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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
