Description
I wrote a Gist on this earlier, but @karenetheridge made me realise a gist is probably a bad format for discussion.
The full body of it is here: https://gist.github.com/kentfredric/a5c902e7d9fa801e4168 , but the top keys are:
- some kind of structure to convey binary executables as dependencies
- some kind of structure to convey header files and libraries as dependencies[1]
- some kind of structure to convey operating-system specific blocks/requirements ( ie: not in regards to prereqs, but in regards to "this dist wont work here" )
- and some kind of structure to covey "general" interpretations of "Interpreters".
That last one is basically a generalisation of the first, in terms of "This needs a C compiler of some description" or "This needs a C++ compiler" or "This might need a Java VM or a python runtime" etc, etc, but exists due to the obvious breadth of competing technologies for the same scope in this regard.
Also needs some proviso for "requires" vs "recommends" vs "suggests".
It is of course assumed that within the CPAN toolchain, all or most of these traits are impossible to be detected automatically ( especially with regard to versions of dependencies ), but the intent is to have these dependencies structured sufficiently so that a non-CPAN downstream who can manage Non-CPAN dependencies can make use of that data automatically ( as long as they implement the glue themselves ) ( But this is a secondary concern that seems natural once the first is addressed )
But the primary reason is of course to have metadata to help searching and discovery by consumers allowing them to weed out dists and dependencies they're not able to use, and allow any manual interactions they'd be required to complete more apparent.
[1] At this time, this is presently only expressed in terms of "needs library", work needs done here, but comparing with Devel::CheckLib aught to be useful.