Re: Diverting dpkg-architecture
On 6/8/06, Wookey <wookey@aleph1.co.uk> 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.
Reply to: