One more point... GNU Pth specifically states that it only executes on a
single CPU at a time, and that there are some restrictions on what
applications must assume that make it easier to write such
applications. (For example, they need to be MT safe, but not re-entrant.)
Rewriting GNU Pth to use native threads might sound like a great idea,
but it might have unforeseen side effects for applications.
In retrospect, the consuming applications, where possible, should
probably be changed to use native Pthreads. Upstream communities might
not always be receptive to that, because having two underlying runtime
libraries to work with adds complexity for them.
There is not necessarily a single good answer here. This is why in many
of these cases I believe that we might be better off forking our own
branch of the upstream software, such as was done for OpenSSH. It isn't
clear to me that the threshold is appropriate for GnuPG, though.
- Garrett
Wyllys Ingersoll wrote:
> James Carlson wrote:
>
>> Wyllys Ingersoll wrote:
>>
>>> It is unreasonable to burden
>>> the teams that want to bring FOSS code to Solaris to also put in additional
>>> effort to fully "Solaris-ize" the code in question.
>>>
>> If the ARC adopts that position, I think that'll be a substantial change
>> in direction. The stated policy up to this point was that "free
>> software isn't free from cost," and that part of the burden of
>> integrating into [Open]Solaris itself is that the software and/or
>> documentation and/or packaging may well need to be modified in order to
>> be compatible with the system. Doing this might mean engaging the
>> upstream community, or applying diffs, or forking the source, or perhaps
>> some combination of those approaches.
>>
>> I'd thought that this understanding is exactly what the whole "kitchen
>> sink" scheme for random FOSS integration was based on.
>>
>> Has this changed?
>>
>
>
> Note that I said "fully". I'm not advocating abandoning our quality or
> integrating
> obviously broken code. In the past when I have integrated FOSS code to SFW,
> I *have* made patches to make it compile better, fixed bugs, etc and also
> engaged the upstream community to accept the changes back. Whether or not
> they
> accept the fixes is beyond my control.
>
> The changes being discussed for Pth are not bug fixes or build modifications,
> they are a change in the entire design of the library. The whole point of
> Pth is to be a "Portable" thread library that is self-contained and does
> not depend on any other thread libraries. Even if the changes being discussed
> really are "low hanging fruit", it still amounts to violating the goals
> and intent of the package as far as I can tell.
>
> The real "fix" (if you can call it that, since nothing is actually broken in
> its current state) would be to modify the consumers of Pth (GnuPG in this
> case)
> to use the native code and eliminate the need for Pth. I will investigate
> the level of difficulty in doing just that, but I am not going to rewrite Pth
> to use Solaris threads just because we think ours is better (regardless of
> whether
> or not it really is) especially if the code already "just works".
>
>
>
>>> If integrating into ON,
>>> then the argument is stronger, but for SFW packages ideally we like
>>> to just drop in the tarballs from the upstream community and apply a
>>> minimal amount of changes to get it to compile and work.
>>>
>> That's a darned shame. Compiling things and tossing them over the wall
>> is fine for a "contrib" repository or something like the old /opt/sfw
>> "Companion CD," but I don't see how it makes any sense for integrated
>> software.
>>
>> Moreover, I don't see how consolidation matters here. Consolidations
>> set build and integration rules, but from the user's point of view, it
>> matters not whether "SUNWfoobar" was originally integrated via ON or
>> some other consolidation. They're all the same to a user. Thus, the
>> same quality had better be present, or the quality of the result will
>> actually reflect the weakest part of the chain.
>>
>>
>
> Consolidation matters to the project team doing the integration work, that
> is my point. ON rules for integration are significantly more onerous when
> attempting to integrate a FOSS package that already has an established
> configure/compile/install workflow and it is much harder to resync with
> the upstream when new releases come out.
>
>
>
>> If compile-without-changes is the intended new direction, why not just
>> switch to Linux? It'll be way easier, and will have essentially similar
>> results.
>>
>
>
> Compile-without-changes is not the new direction as far as I know, but it
> certainly is a goal. The direction I've heard in the past for SFW projects
> is to apply patches as necessary and work with the upstream community to
> accept
> them so that we can eventually get to the point where we don't have to apply
> patches
> anymore (we ultimately would like to be "compile-without-changes").
>
> -Wyllys
>
