On 6/8/06, Wookey <[EMAIL PROTECTED]> wrote:
This should be easy to do and I can see no real reason not to do it, at least for the meantime, until a better solution in dpkg itself is achieved (see below).
The point is that current tendency of dpkg-cross is toward using dpkg-architecture as the only source of architecture-related strings (drop %archtable/%crossprefixtable/%whateverelsetable), so we'll at least have to discuss a better way to do so.
> Alternatively, is there any chance we can get a number of uclibc-* > architectures into mainstream dpkg? [archname-related flame > discouraged] This would be better than the above diversion, but is probably harder to acheive. Have you asked the maintainers directly, along with a patch yet? If not then I suggest you do so and see what they say.
The other thing is, we don't really want these architectures in debian, they make sense only for cross-compilation, which is why I think it's better to keep them in dpkg-cross only.
I know you asked to avoid name-discussion, but personally I think you will struggle to get this accepted in mainstream without agreeing a more-complete scheme for arch-naming. I think arm-uclibc type names are better in the long term, and more likely to be accepted than uclibc-arm type names, but ultimately it is up to the dpkg maintainers. A proper summary of the issues around arch-names on the wiki would be useful in order to have something to point people at when this issue comes up (precisely to keep discussion productive and flameage minimised). Such a text is needed as justification/explanation for the inclusion of the new arches in dpkg anyway, I suspect. I do not feel sufficiently expert to write such a text myself, but would help with review.
There were some threads on this list regarding architecture names, they can be used as a basis should you (or someone else want to write a wiki page). However, no patches to support such names in dpkg were suggested. Which is why I want to avoid this sort of discussion for now; I just want uclibc architectures. If a decent implementation shows up, we could bring this topic up once again. Before that happens, I prefer to think of uclibc architectures as uclibc-$cpu. -- I am free of all prejudices. I hate every one equally. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
