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.


msgh id

Shared Libraries


Transition to "normal" ELF symbol versioning/libtool?

For all libraries, the SONAME is currently set to 0.3. Not changed when doing the Hurd 0.5 release.


Bump the glibc SONAME to some point, or can do everything with symbol versioning?

There are some comments in the sources, for example hurd/geteuids.c: XXX Remove this alias when we bump the libc soname.

IRC, freenode, #hurd, 2012-12-14

In context of packaging libpthread/libpthread.

<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...


time_t -- Unix Epoch vs. 2038

IRC, freenode, #hurd, 2013-12-12

<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:
<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