On 3 November 2016 at 21:40, Nick Coghlan
On 3 November 2016 at 05:28, Nathaniel Smith
wrote: On Nov 2, 2016 9:52 AM, "Nick Coghlan"
wrote: Tennessee Leeuwenberg started a draft PEP for that first part last year: https://github.com/pypa/interoperability-peps/pull/30/files
dnf/yum, apt, brew, conda, et al all *work around* the current lack of such a system by asking humans (aka "downstream package maintainers") to supply the additional information by hand in a platform specific format.
To be fair, though, it's not yet clear whether such a system is actually possible. AFAIK no one has ever managed to reliably translate between different languages that Linux distros use for describing environment constraints, never mind handling the places where they're genuinely irreconcilable (e.g. the way different distro openssl packages have incompatible ABIs), plus other operating systems too.
The main problem with mapping between Debian/RPM/conda etc in the general case is that the dependencies are generally expressed in terms of *names* rather than runtime actions, and you also encounter problems with different dependency management ecosystems splitting up (or aggregating!) different upstream components differently. This means you end up with a situation that's more like a lossy transcoding between MP3 and OGG Vorbis or vice-versa than it is a pristine encoding to either from a losslessly encoded FLAC or WAV file.
The approach Tennessee and Robert Collins came up with (which still sounds sensible to me) is that instead of dependencies on particular external components, what we want to be able express is instead a range of *actions* that the software is going to take:
- "I am going to dynamically load a library named <X>" - "I am going to execute a subprocess for a command named <Y>"
And rather than expecting folks to figure that stuff out for themselves, you'd use tools like auditwheel and strace to find ways to generate it and/or validate it.
I don't think thats what we had proposed though its similar. My recollection is proposing that dependencies on system components be expressed as dependencies on the specific files rather than on abstract names. Packaging systems generally have metadata to map files to packages - and so a packaging specific driver can map 'libfoo1.2.so' into libfoo-1.2 on Debian, or libfoo1.2 on a slightly different naming style platform. The use of a tuple (type, relpath) was to abstract away from different FSH's. ABI's for libraries are well established and at the control of upstream, so there's no need for random audit tools :). -Rob