From f9b2dbf69992c03e13f6a2b89c5d1e900fc671b5 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 31 Jul 2010 23:55:25 +0200 Subject: open_issues/packaging_libpthread: New. --- open_issues/packaging_libpthread.mdwn | 47 +++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 open_issues/packaging_libpthread.mdwn diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..7594ae76 --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + My idea was to have a separate libpthread package. What do you think about that? + in the long term, that can't work with glibc + because of the thread stub stuff + it's not really possible to keep synchronized + because you have to decide which package you unpack first + (when upgrading) + 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? + ... for incompatible forward changes? + that'd be a mess to maintain + Drepper doesn't have this constraint and thus adds members of private fields at will + OK, but how is it different then if the libpthread is in the Hurd package? + I'm not saying it's better to have libpthread in the Hurd package + OK. + I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + Then, to goal is to have it in glibc? + OK. :-) + OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. + So our official goal is to have libpthread in glibc, at least for Debian purposese? + for any port purpose + Ack. + provided you're using glibc, you're deemed to ship libpthread with it + because of the strong relations Drepper puts between them + (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) + yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + (would be nice to not have those issues anymore...) + 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.) + Does that sound about right, or am I missing something fundamental? + I actually don't know what a git submodule permits :) + looks like a good thing for this, yes + Unfortunately I can't allocate much time at the moment to work on this. :-/ + well, as long as I know where we're going, I can know how to package stuff in Debian + That sounds like a plan to me. libpthread -> glibc as submodule. + (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) -- cgit v1.2.3