Re: uClibc status
On Fri, Oct 31, 2008 at 07:40:41AM +0000, Neil Williams wrote:
>On Thu, 2008-10-30 at 22:38 +0100, Simon Richter wrote:
>> - On all architectures, the package "uclibc0.9.30rc3" contains all
>> run-time libraries in a single package.
>
>Do we need the full version string within the package name? Is the ABI
>that unstable? Is it likely to stabilise? I don't fancy all those binary
0.9.30 should be binary compatible to 0.9.29.
>rebuilds. Or is that actually "uclibc_0.9.30rc3" or uclibc0? uclibc0.9
>might be OK.
> ^^^
>> - 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.
>
>That forces every reverse depends to update to the latest uclibc every
>time a new upload is made, it doesn't allow for migrations where
>lib32uclibc0.9-dev sits alongside lib32uclibc0.10-dev. glibc transitions
>are painful and protracted.
>
>> 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
>
>libc0.9uc ? Is that ABI really going to change that much between rc3 and
>rc4 or between 0.9.30* and 0.9.31 ?
Due to potential TLS and/or NPTL support in 0.9.31 it is possible that
.31 will require rebuilds of dependent packages.
Reply to: