Re: Diverting dpkg-architecture
-----BEGIN PGP SIGNED MESSAGE-----
Alexander Shishkin wrote:
> On 6/8/06, Wookey <firstname.lastname@example.org> 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
>> (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
>> struggle to get this accepted in mainstream without agreeing a
>> 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
>> 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
Which is not true. This
is there since march, and I've been using this successfully for quite
> could bring this topic up once again. Before that happens, I prefer to
> think of uclibc architectures as uclibc-$cpu.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----