Hi! On Mon, 2016-04-18 at 00:08:57 +0200, Patrick Schönfeld wrote: > I understand that it would be bothersome and therefore I understand your > position, yet I ask to reconsider my request :)
After my enquiry about several of the alternative implementations for things that libdpkg-perl is already doing, I see this is an important factor when people decide to use a perl module, so I've registered on PAUSE, and I've been playing a bit with generating a perl distribution from the stock «make dist», I'll try finish that up and merge, ideally during the 1.18.x series: <https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/cpan> > 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? Not all but many depend on modules that make use of those modules. The problematic ones are Dpkg::Deps wich relies on dpkg to find the build arch, and Dpkg::Path which relies on dpkg-query to find the control path in the dpkg db, although the second is not used at all by any module, so it's probably not that bad. Thanks, Guillem
