Re: Requirements for specifying dependencies on libraries

[Jens Rehsack <rehsack%gmail.com@localhost>]

Am 15.03.2014 um 16:32 schrieb Greg Troxel <gdt%ir.bbn.com@localhost>:

> 
> Jens Rehsack <rehsack%gmail.com@localhost> writes:
> 
>> I mean in terms of developer - the person who writes that down before
>> uploading a package upstream. So it could look like:
>> {
>>   "abstract" : "Provide the stuff missing in List::Util“,
>>   "prereqs" : {
>>      "runtime" : {
>>         "recommends" : {
>>            "perl" : "5.018001"
>>         },
>>         "requires" : {
>>            "Sub::Exporter" : "0",
>>            "XSLoader" : "0",
>>            "perl" : "5.008001"
>>         },
>>         "linking" : {
>>            "libgcrypto.la" : "20"
>>         }
>>      }
>>   }
>> }
> 
> I find this a bit strange.  Are you saying that the perl module
> distribution (that lives in CPAN, that a packaging system like pkgsrc
> would download, or that a user would) would really have a baked-in
> requirement for major version 20 of a shlib?  Would it also have the
> path baked in?

No! The question I asked is: how can we canonical identify such a shared
library to guess the right package (or builtin.mk) from.
The example above is something how it _could_ look like, not like it looks.

In case of specifying dedicated shared libraries (which is finally the
thingie which is linked against), which version number should be specified?
I simply assumed, the number of the shared library (and for real: I neither
know nor care which is the recent major library version of libcrypto, because
neither I maintain libssl nor Net::OpenSSL ^^).

> If this isn't already baked in, why is depending on the release version
> of the package that contains the dependency insufficient?

Because libssl has different version numbers. The one delivered with AIX
has a number from IBM (neither the implementation has necessarily anything
in common with OpenSSL).

We are still in some kind of negotiating how such a version could be
specified (and thing becoming more complicated - also header files or
executables might be a requirement, eg. thinking about the Perl interface to
Wx (requires headers) or Archive::Tar (requires executables)).

> Or is this about providing metadata to be used by packaging system?
> 
>>> Are perl modules configured to dlopen particular shlib versions?  Really
>>> the version number is arbitrary per OS and can be changed by packaging,
>>> so that seems somewhat fraught.
>> 
>> It’s more a question of proving before - to have an option to reject
>> versions which lack requirements (there is no "must“ - you always can
>> specify 0).
> 
> I see - but still the question would seem to be about having a
> particular version or higher (or maybe NOT higher??) of some other
> package, not the shlib major version and path.

That’s why I’m asking - I want to read other opinions. My background might
be insufficient to drive the spec alone (but I seem to have the most
experience at the particular group which is interested to improve toolchain
here).

Cheers
-- 
Jens Rehsack
pkgsrc, Perl5
sno%NetBSD.org@localhost