tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Requirements for specifying dependencies on libraries

Am 15.03.2014 um 00:36 schrieb Greg Troxel <>:

> Jens Rehsack <> 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.,,,
>> ...). 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" : {
            "" : "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/
>  /usr/pkg/lib/
>  /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).

Jens Rehsack

Home | Main Index | Thread Index | Old Index