Guillem Jover wrote:
Sure, no problem with that, it's always good to have bugs on file, but
the only problem here is trying to overload the meaning of armel for a
different architecture.
I understand. But surely we can choose a different name (uarmel?) and
after we've agreed with the arch naming scheme, this can be implemented
properly.
The proper fix (if desired) is to create a name for this supposed
uclibc based architecture. Then those warnings go away by themselves.
Agreed. The patch was only intended as a temporary solution. I'd rather
see a working package with somewhat conflicting architecture, than no
package at all and an error message when trying to build the package.
I'm tempted to close this bug report unless there's someone starting a
real Debian arm eabi uclibc port.
Sure.
However, the core problem is not entirely armel related. When we want to
use something else than glibc (uClibc, Newlib, dietlibc, Klibc, ...) in
any architecture, we want (generally) those packages to be of different
arch than the ones built against "vanilla" glibc.
Therefore, it would be reasonable that a uniform naming scheme would
exist in the architecture names.
When we have an idea what that scheme could be, we can reimplement the
patch properly.
Regards,
Jussi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
