Hi, I understand that it would be bothersome and therefore I understand your position, yet I ask to reconsider my request :)
2016-04-16 12:56 GMT+02:00 Guillem Jover <guil...@debian.org>: > > Which means many if not most major distributions (and their > derivatives) already provide them: > Indeed and I did not notice that it's even available on OSX where I could have needed it. So thanks for the hint. Still, I see value in providing Debian-specific libraries via CPAN. The tools available in the packaging ecosystem allow installing packages independently from the system package manager, apart from that they can manage several different versions of a library for different perl versions, which is quiet handy as a developer. Consider the following use case: A developer want's to write a tool to query depends of a perl application from debian/control files, so that this can be the source of truth for what dependency the application has, even when developing and therefore running it on a developers OSX notebook (where he'd use the tools in perl ecosystem to manage the depends). Since the application itself can run on OSX just fine, there is no reason why this tool couldn't run on OSX. It would also help to manage dependencies for various target platforms, keeping them in sync. There is a library for this and maybe other use cases and it is most likely to be in sync with the policy. It would be quiet cool if a random perl developer could use it and get it via standard means, e.g. cpanm. Currently there is no library for parsing Debian dependencies on CPAN (at least I haven't found one that doesn't depend on other Dpkg::* libraries) and even if there were one, it wouldn't be the reference implementation. I agree that something like that will always have limitations, e.g. if the libraries in fact require dpkg binaries, but not all of the dpkg perl libraries do have those limitations, do they? Best Regards, Patrick
