[followup changed to tech-pkg, as this is larger in scope than the usual
pkgsrc-changes discussion]
Matthew Mondor <mm_lists%pulsar-zone.net@localhost> writes:
> On Thu, 01 May 2014 20:30:16 -0400
> Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
>> So given the bug history, it seems that boehm-gc with threads is likely
>> the normal case, and we need to add a boehm-gc-nothreads package, and
>
> Historically in pkgsrc threads were disabled by default for boehm-gc,
> until very recently. The intent of pkg/41893 was originally to enable
> threads by default, but then it became evident that some issues existed.
>
> On some Linux distributions, it's indeed now enabled by default (i.e.
> on Ubuntu); but I also could not reproduce the same bugs on Linux when
> I last tried.
I realize it's been unthreaded in pkgsrc historically. But I meant that
in the larger free software world, it seems that the threaded version is
considered more normal.
(I see this has been reverted for now, but we still need to figure out
what to do.)
So where we are, as I see it:
threads being enabled is currently dependent on platform. That
doesn't make sense, and is counter to the pkgsrc way. (It probably
means that ecl fails on Darwin, but maybe it's broken anyway.)
It seems we have a situation where many uses of libgc need or desire
threads, perhaps more than half (but it's not clear), but there is at
least one known case (ecl) where that causes trouble. But, the most
prominent user of ecl is using it threaded and avoiding the bug -- so
the idea that boehm-gc should not be built threaded because of ecl
does not have a lot of support. The PR does not contain other
examples.
Overall in the free software world, the normal case for libgc is to be
threaded.
From that, it seems clear that pkgsrc needs to support threaded and
nonthreaded boehm-gc. The two questions are:
Should these two be parallel-installable? (Clearly it would be nice,
but it's not clear that it's mandatory.)
Which version should the unadorned name use?
My impression is that the unadorned name should be threaded, as that's
where the world seems to be and likely more where it's headed. Having a
second package for unthreaded but with colliding names is pretty easy.
As for parallel-installable, it seems awkward to rename everything for
the alternate version, but perhaps only renaming things under lib and
only installing those is sensible. Another approach is to build it in
a subprefix, e.g. ${PREFIX}/nothreads, for use by non-pkgsrc and pkgsrc
programs. The multiple versions of guile did this.
So from the PR, it seems the only known case of lossage is ecl, but
there is general concern about how stdio's locking and libgc's locking
interact.
The other question is who is going to do what work, and in what stages.
So I'd say that if anyone wants to create a boehm-gc-nothreads package
(without requiring it to not conflict), it's then ok to flip boehm-gc
back to threads, and any depending packages that have trouble with that
can then just move to the nothreads version. That will result in being
able to install either the threaded or the nonthreaded version. This is
not really a regression, because right now packages can't be built with
thread support, so we essentially have a forced option. Having two that
couldn't be installed together would be more flexible than what we have
now, and more useful for binary package users.
Then, if someone wants to change the nothreads version to not conflict,
that would be great. But I don't think we should hold up incremental
progress based on that not being done.
Attachment:
pgpbODdrbqpHY.pgp
Description: PGP signature