Re: hppa nptl switch
Interesting, I wasn't aware that this was a requirement of a partial
upgrade. Thanks for bringing this to my attention. I'll go back and
have a look at your previous proposal.
The static initializer are (re-)exposed by some headers like
<X11/Xthreads.h>, <directfb/direct/modules.h>.
There is no guarantee that library and applications are compiled
against the same set of (e)glibc headers.
GLIBC does not guarantee this type of compatibility. When upstream
GLIBC versioned the pthread_cond_t interfaces there were exactly the
same guarantees that I provide now. All parts of the program must use
the same ABI.
How did debian handle the pthread_cond_t changeover in 2.3.2?
I do not know what changed in 2.3.2 in linuxthreads/condvar.c,
there is obviously some padding in pthread_cond_t. As long as the size
of pthread_cond_t remains the same and "bytes" initialized in the new
initializer are the same as "bytes" in the old initializer, it should be OK.
Of course, old initializer might initialize more bytes compared to new
one.
So, every time that upstream breaks ABI, does it cause a serious
problem for partial upgrades?
There has never been support for a mixed-ABI, which is what you are asking for.
I am asking for
* sizeof() have to be the same for old and new structures
* new functions have to cope with old static initializers properly
* pthread_mutex_t.__m_kind have to retain the same offset,
similarly for other user specifiable attributes in initializers
I would describe it as be-backward-compatible.
You did express some concern that these configurations should work,
but you never identified that these were specifically important to the
debian upgrade process.
To clarify, I am not member of release team, in fact I am not even DD.
AFAIK, it should be possible to start with plain lenny installation,
upgrade some packages to (current) squeeze and all should still work.
Cheers
Petr
Reply to: