Re: Requirements for specifying dependencies on libraries

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

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

> 
> Jens Rehsack <rehsack%gmail.com@localhost> writes:
> 
>> since I currently attend the annual Perl Q&A Hackathon, where
>> traditionally most important toolchain people sit together and talk
>> about ways to improve Perl and CPAN, we talked about packaging and how
>> to support that.
>> 
>> We come to the conclusion, that in the machine readable meta
>> information a field shall be provided which names the requirements of
>> external libraries (eg. libfile.so, libstatgrab.so, libfetch.so,
>> libssl.so ...). This name should be in a canonical way.
>> 
>> Here comes the question: from pkgsrc point of view, how such a
>> canonical name should look like?
> 
> The notion of specifying libraries can come in two ways.  One is
> relative to a source package, in terms of what it needs, and there it’s

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"
         }
      }
   }
}

> about API.   The other is about particular shlib versions, afer a
> package has been built.  Then, I can see three ways, and (picking
> libgcrypt without loss of generality), I can see:
> 
>  /usr/pkg/lib/libgcrypto.la
>  /usr/pkg/lib/libgcrypto.so.20
>  /usr/pkg/lib/libgcrypto.20.dylib
> 
> The first one seems to be present on most systems, but only works for
> packages that use libtool.  And the filename doesn't have the version,
> but it's in the file.  The second works on normal computers (with an ELF
> bias, how quickly we don't even remember when an a.out library looked
> like in detail) and the last one on Macs,
> 
> So if you're really talking about ABI of a built package, then I think
> it's either so or dylib.
> 
> 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).

Cheers
-- 
Jens Rehsack
rehsack%gmail.com@localhost