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?
If this isn't already baked in, why is depending on the release version
of the package that contains the dependency insufficient?
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.
Attachment:
pgp95yubvU7aG.pgp
Description: PGP signature