On Fri, May 07, 2010 at 11:50:39AM -0400, Jeffrey B. Green wrote: > 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.
just nuke the trunk linux-image, it is severely outdated. kind regards -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
