Hi, Daniel Ruoso wrote:
I'm interested in maintaining a i386-uclibc architecture, which is, like the name says, i386 binaries linked with uClibc. My plans are:
Well, I need an ARM bigendian uclibc port, so chances are I'm the one to coordinate with the armbe people (in fact my personal dpkg already knows of these arches).
However, I can see the number of configurations to be somewhat large, so I wonder whether it makes sense to call it a new architecture (especially as uclibc binaries can happily coexist with glibc binaries as long as the same binary does not use both libraries indirectly. Given that the number of packages that make sense to run on such a system is somewhat limited, I would start out by creating "regular" i386 packages that just happen to be linked against the uclibc; said packages should be built from a special build target that is not invoked by default and generate packages with a -uc or similar suffix. For libraries, I'd even go as far as to change their soname so they can be concurrently installed to the glibc variant.
This approach has several advantages: - You don't need a new arch - You can start with replacing single packages inside a running system- The packages can be added into the main archive easily if this is desired later.
The i386 packages won't be compatible with my i386-uclibc environment (as I won't have glibc installed). So I started calling the architecture i386-uclibc with gnu name i386-uclibc-linux. And I'd like to ask: Is it OK?
The alternative would be to rename i386 to i486 and call the new port i386. But that would be an evil transition.
Simon
signature.asc
Description: OpenPGP digital signature
