On 03/10/15 13:01, Frank Ch. Eigler wrote:
> "Ken McDonell" <kenj@xxxxxxxxxxxxxxxx> writes:
>
>> [...]
>> perl(LWP::UserAgent) is needed by
>> pcp-pmda-elasticsearch-3.10.8-1.x86_64
>> perl(LWP::UserAgent) is needed by pcp-pmda-nginx-3.10.8-1.x86_64
>> Now there is apparently no perl-LWP-UserAgent rpm for this SuSE version.
>
> Iam assuming those LWP::UserAgent libraries are actually needed by those
> pmdas.
Yep.
kenj@bozo:~/src/pcp/src$ grep -r 'use.*UserAgent' *
pmdas/activemq/pmdaactivemq.pl:use LWP::UserAgent;
pmdas/elasticsearch/pmdaelasticsearch.pl:use LWP::UserAgent;
pmdas/nginx/pmdanginx.pl:use LWP::UserAgent;
pmdas/nginx/Install:perl -e "use LWP::UserAgent" 2>/dev/null
>
>> [...]
>> 1. how should I fix this for the SuSE QA machine?
>
> ...
The "fix" was to discover that in the the wonderful world of RPM packaging
anarchy, SuSE and RedHat have made different choices about how to package the
LWP:UserAgent ... in suseland you need to install perl-libwww-perl in
redhatland you need to install perl-LWP-UserAgent.
Once I discovered this (and that in itself is a non-trivial task), and taught
qa/admin/check-vm about it, everything "just worked"(tm) again.
>> 2. should this sort of dependency really belong in the packaging?
>> We don't do it at all for dpkg and we cannot do it for tarball, so
>> this really means the pmda install scripts need to check in the
>> required Perl modules are present.
>
> IMHO definitely yes. Automatic satisfaction of dependencies is just
> what distro packaging is supposed to accomplish. A run-time check is
> a last-ditch effort to make perl errors more intelligible.
I agree ... it would just be nice if it was simpler to find where the
functionality you need has been cunningly packaged across all the distros.
>
>> 3. even if this should be in the rpm packaging, should it not (a) be
>> consistent and (b) work without surprises?
>
> Sure (though consistent with what?).
We should treat the activemq PMDA the same way, as it uses the LWP::UserAgent
module, but does not have the dependency in the spec files ... I have fixed
this in a commit that will flow soon.
|