Things to consider regarding versioning.
The provider and user of any interface need to agree about how to interpret the data being exchanged. Internal-only interfaces can be changed easily, because you can change the provider and user at the same time. Interfaces that are exposed externally require more attention, for obvious reasons. To change interfaces means to either remove, or add, or modify an existing interface. Modify basically means to remove and then re-add a variant, re-using the former name/identifier.
Transition to "normal" ELF symbol versioning/libtool?
Bump the glibc SONAME to some point, or can do everything with symbol versioning?
There are some comments in the sources, for example
Remove this alias when we bump the libc soname.
<pinotree> once libc is switched internally from cthreads to pthreads (thus breaking its BC), may be worth cleanup the hurd-specific exported symbols <tschwinge> pinotree: Yes. If you already have ideas about what to clean up, feel free to add a new page or a section on open_issues/glibc. <pochu> we're gonna break backwards compatibility in glibc on hurd? that could be the perfect moment to fix the /dev/fd/N problem without adding new RPCs, though we'd probably have to break backwards-compatibility in the exec server IIRC...
<azeem> because it gets discussed in #debian-devel for the Linux i386 architecture right now: what's the deal with hurd-i386 and the 32bit epoch overflow in 2038? <braunr> what do you mean ? <azeem> braunr: http://lwn.net/Articles/563285/ <braunr> ok but what do you mean ? <braunr> i don't think there is anything special with the hurd about that <azeem> well, time_t is 64bit on amd64 AIUI <braunr> it's a signed long <azeem> so maybe the Hurd guys were clever from the start <azeem> k, k <braunr> our big advantage is that we can afford to break things a little without too much trouble <braunr> in a system at work, we use unsigned 32-bit words <braunr> which overflows in 2106 <braunr> and we already include funny comments that predict our successors, if any, will probably fail to deal with the problem until short before the overflow :> <azeem> luckily, no nuclear reactors are running the Hurd sofar <braunr> i wonder how the problem will be dealt with though <braunr> ah, openbsd decided to break their abi <azeem> yeah <braunr> that's probably the simplest solution <azeem> "just recompile" <braunr> and they can afford it too <azeem> yeah <braunr> good to see people actually worry about it <azeem> I guess people are getting worried about where Linux embedded is being put into <braunr> they're right about that <azeem> "Please, don't fix the 2038 year issue. I also want to have some job security :)" <braunr> haha