[Bug 335666] Re: libc6 integration gives way wrong error message to libc5 binaries.

[Zygmunt Krynicki]

** Changed in: command-not-found
       Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to command-not-found in Ubuntu.
https://bugs.launchpad.net/bugs/335666

Title:
  libc6 integration gives way wrong error message to libc5 binaries.

Status in command-not-found handler:
  Won't Fix
Status in “command-not-found” package in Ubuntu:
  Confirmed
Status in “linux” package in Ubuntu:
  Won't Fix

Bug description:
  Binary package hint: libc6

  I know from the start I'm asking for something that doesn't fit in a
  simple place.

  The problem goes like this:
  The way libc6 has been integrated, any libc5 binaries that are run will give a way wrong error message.

  For example, clueless users running old programs out of remotely
  mounted filesystems:

  WDC-ATHENA-2% which ez
  /mit/andrew/arch/i386_linux24/bin/ez
  WDC-ATHENA-2% ez
  ez: Command not found.

  The problem is NOT that the ez binary is not found. The problem is that there is no ld-linux.so.1 to help link
  in libc5.  The reason for this is, sensibly, there IS no libc5 installed.

  What needs to happen is that the person running the program needs to be told that the binary is so old
  that it's linking against libc5 when it needs to be recompiled against libc6.

  Instead the user is told that the file that can be accessed from
  myriad file utilities does not exist.

  I suggest a work-around:

  a Recommends /lib/ld-linux.so.1 that gets installed if none is present that will at least
  print an error message that makes sense.

  Since Ubuntu is all about the usability experience, I hope I'm not off
  base here asking for this amendment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/command-not-found/+bug/335666/+subscriptions