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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
