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 <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
Home |
Main Index |
Thread Index |
Old Index