Bug #103392 for Log-Dispatch: Should not depend on threads.pm

And it is factual that this feature *does* require threads.

perl -MLog::Dispatch::Syslog -E"Log::Dispatch::Syslog->new( min_level => 1,   lock => 1 )"
This Perl not built to support threads
Compilation failed in require at /home/kent/perl5/perlbrew/perls/5.21.8-c/lib/site_perl/5.21.9/Log/Dispatch/Syslog.pm line 62.

But the rest of it does not. Which is where it gets sticky.

Thus, whether or not it requires threads is conditional on usage.

But when it does require threads, it *also* requires a threaded perl.

And the prevalence of this is sufficient to make that inference in general.

But the problem is for downstream, there's no opaque way to tell if a dist actually need threads or not. Which is why the dependence on threads.pm , given the above behaviour, is a proxy for "needs a threaded perl". And this is mostly reliable.
 

And by proxy, any module that uses this feature inherently requires a threaded perl.

And this is *also* an invisible mechanism which is not visible anywhere other than the declared chain of dependencies.

So given that X requires threads, and that threads.pm requires a threaded perl, and that Y requires X, by inference, to provide X, we must provide a threaded perl for module Y.

We can of course bodge around it downstream, but we can't do better in initial packaging than to assume that "requires threads" is sufficient cause to force a threaded perl being available.

On 2015-04-09 10:28:25, ETHER wrote:
> No. %Config should be checked in Makefile.PL if threads are required,
> and exit or die otherwise.
>

That would make sense if the whole module required it, instead of just a feature... but its murkier with optional features ( And optional features that are determined at runtime are all kinds of hell for downstream, because it basically means there are side effects that can be indicated by things outside their vendor dependency spec set )

> It is incorrect for this distribution to be depending on threads.pm
> when it isn't used by a core piece of functionality, but I think the
> gentoo packager is also in error for not being able to transcribe
> these dependencies into something that works in a non-threaded perl.

It is a transcription problem, but its the sort of thing that you can only realize is wrong after the fact.

Because it /is/ very much the case that we try to transcribe upstream dependencies directly to downstream dependencies where possible, and that we report dependencies being inaccurate upstream when we encounter them downstream. ( I'll come back to that later )

And because of the nature of threads.pm, where one _cannot_ *use* it without a threaded perl. Yes, EUMM and MM and friends can all do static analysis of it, but for all points and purposes in the context of downstream dependencies, what *actually* happens at *runtime* is important.

For instance, if there is an arbitrary module named "A" and it requires arbitrary module "B", it doesn't matter that A is on your system and can have its version statically parsed with EUMM, it is considered *broken* from a runtime perspective if `use A` cannot be expected to work at all.

( And we do frequently have this problem when upstream splits a package and so the module is secretly gone in a subsequent release, and nobody noticed, and so there is now things that depend on that that have to be fixed. )

Thus, we deem "threads" to be "unusable" in runtime without a perl with threads enabled ( despite being available )

And so by proxy, any mapping of an upstream to dependency to "threads" maps to the downstream dependency "virtual/perl-threads".

And _that_ dependency is tasked with making sure threads.pm is `use` able. And so it naturally requests the user provide `dev-lang/perl[ithreads]` to guarantee a perl with thread support.

This is indeed a problem of various many faceted joys of mapping several incompatible systems of dependency mappings and the contrasting axioms of  "Just-works" logic against a stricter "It must work as soon as its installed or make it clear it wont work before the code even runs" system.

But that is why the intent of dependencies in *.json and *.PL need to be clear.

Because we have to map upstream dependencies verbatim in initial packaging passes, and hope we did our best. Because its simply not viable to perfectly assess very far beyond that.

Often upstream will depend on stuff and it won't be obvious why or how, and it will only be discovered later. So its better to over-specify and have the dependency resolver go "Welp, I cant be satisfied, need a different perl" than to under-specify and have a machine somewhere randomly not work later in the installation cycle.

Sometimes upstream under-specify, and that's not something we really are likely to notice so readily, and those cases until somebody files a bug, and then we file a bug upstream to make the missing conditional dependency visible in some manner.