IRC, #hurd, 2010-07-31

<tschwinge> My idea was to have a separate libpthread package.  What do you think about that?
<youpi> in the long term, that can't work with glibc
<youpi> because of the thread stub stuff

libpthread dlopen, for example.

<youpi> it's not really possible to keep synchronized
<youpi> because you have to decide which package you unpack first
<youpi> (when upgrading)
<tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages?  It isn't atomic either way?  Aren't sonames / versioned library packages solving that?
<tschwinge> ... for incompatible forward changes?
<youpi> that'd be a mess to maintain
<youpi> Drepper doesn't have this constraint and thus adds members of private fields at will
<tschwinge> OK, but how is it different then if the libpthread is in the Hurd package?
<youpi> I'm not saying it's better to have libpthread in the Hurd package
<tschwinge> OK.
<youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc
<tschwinge> Then, to goal is to have it in glibc?
<tschwinge> OK.   :-)
<tschwinge> OK, I can accommodate to that.  Isn't not that we'd want to switch libpthread to something else so quickly.
<tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese?
<youpi> for any port purpose
<tschwinge> Ack.
<youpi> provided you're using glibc, you're deemed to ship libpthread with it
<youpi> because of the strong relations Drepper puts between them
<youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance)
<pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used
<pinotree> (would be nice to not have those issues anymore...)
<tschwinge> So -- what do we need to put it into glibc?  We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.)
<tschwinge> Does that sound about right, or am I missing something fundamental?
<youpi> I actually don't know what a git submodule permits :)
<youpi> looks like a good thing for this, yes
<tschwinge> Unfortunately I can't allocate much time at the moment to work on this.  :-/
<youpi> well, as long as I know where we're going, I can know how to package stuff in Debian
<tschwinge> That sounds like a plan to me.  libpthread -> glibc as submodule.
<youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so)