Hi, I'm still in the middle of packaging the 0.9.30rc3 candidate. There will be a lot more binary packages than before: - On all architectures, there is a single package "libuclibc-dev" that provides whatever is necessary to build software against uclibc For the "debian" vendor: - On all architectures, the package "uclibc0.9.30rc3" contains all run-time libraries in a single package. - On 64-bit architectures that have a -m32 variant (amd64 only, I think), "uclibc32-0.9.30rc3" provides a 32-bit build, and "lib32uclibc-dev" provides the static libraries and .so symlink for that. - Likewise, 32-bit architectures with a meaningfule -m64 variant (i386, powerpc, sparc, mips) get "uclibc64-0.9.30rc3" and "lib64uclibc-dev" packages - All other ABI-changing variants are thrown together in a big package "uclibc0.9.30rc3-multilib". This package exists only on architectures where there actually are such variants, of course. For the "emdebian" vendor: - On all architectures, "libc0.9.30rc3uc" provides libc, "libm0.9.30rc3uc" contains libm, and so on. - 32/64 bit variant builds are named "lib32c0.9.30rc3uc" and "lib64c0.9.30rc3uc", respectively I'm unsure whether to build -pic and -dbg packages right now, and if so, whether to build them for the 32, 64 and multilib packages as well. The other thing I'm still undecided on is the "other variant" builds for the "emdebian" vendor: I can see an use case for a separate "libc0.9.30rc3uc-thumb" package, but I don't see how I could generate the package names in a sane way (also "libc0.9.30rc3uc-big-endian" makes no sense to have on a LE system, only when building software against it), so I'm thinking about handling the options where it makes sense to have fine grained runtime packages in the same "special" way that I handle 32/64, and just lump the rest together into a huge "multilib" package or omit them completely. Questions, comments? Simon
Attachment:
signature.asc
Description: Digital signature