Hello, I disagree on 2 points:
1. The bug should be assigned to libc6 instead of libc6-i686, because it's equally applicable to all architectures, including i386 of course. 2. The severity isn't minor in any way, because: * the bug potentially affects a lot of packages that use getopt_long_only() * it introduces a whole new class of ambiguities that were not even mentioned in getopt's documentation _and_ were ignored in implementation altogether, AFAIS * the current getopt_long_only()'s behaviour is completely against any expectation or common sense, that greatly increases risk of programming errors and bugs Citing man getopt_long_only: > getopt_long() and getopt_long_only() also return the > option character when a short option is recognized. > For a long option, they return val if flag is NULL, > and 0 otherwise. Error and -1 returns are the same > as for getopt(), plus ’?’ for an ambiguous match or > an extraneous parameter. * there's no "option `-l' is ambiguous" warning message generated at all, or '?' returned for short vs. long option ambiguity. (you get the '?' and warning when there's amgiguity between 2 long options (e.g. '-longa' vs. '-longb')). * curent resolution of ambiguities is inconsistent, because it prefers long option in one case and short one in all others (see below): There's no description about how the current implementation resolves short vs. long option ambiguities, and the actual rule is the next (JFYI): a) lone (unbundled) short option '-l': '-l' vs. '--long' => short option takes precedence b) bundled short option in beginning of a bundle '-ls': '-l' '-s' vs. '--long' '-s' => short option is chosen ('-l' '-s') c) bundled short option in middle of a bundle '-Sls': '-S' '-l' '-s' vs. '-S' '--long' '-s' => short option is chosen ('-S' '-l' '-s') d) bundled short option at end of a bundle '-sl': '-s' '-l' vs. '-s' '--long' => long option is preferred here ('-s' '--long') -- IMHO this doesn't qualify as a minor bug. Regards, xrgtn