Bug#821177: dpkg: please make dpkg perl libraries available on cpan

[Guillem Jover]

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:

  

> 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

Bug#821177: dpkg: please make dpkg perl libraries available on cpan

[Patrick Schönfeld]

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 :
>
> 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

Bug#821177: dpkg: please make dpkg perl libraries available on cpan

[Guillem Jover]

Hi!

On Sat, 2016-04-16 at 12:02:35 +0200, Patrick Schoenfeld wrote:
> Source: dpkg
> Severity: wishlist

> as of today it's not possible to use the perl-libraries in the Dpkg::
> namespace on systems other then Debian (except someone packaged
> them for the target system, like it has been done in Fedora).

Which means many if not most major distributions (and their
derivatives) already provide them:

  

> Since the perl ecosystem does have it's own platform for modules with
> it's own tooling (which we as a distribution happily benefit from, when
> packaing perl modules), it would be very nice if Debian made their own
> libraries available on CPAN, too.

TBH I don't consider language specific packaging ecosystems a feature,
as that falls apart in many cases, such as when a project provides
multiple language bindings. For pure such language specific code using
those ecosystems as just a distribution channel seems fine so that others
can package them properly for their systtems though. :)

> Some Debian projects already do, unfortunately dpkg is a prime example
> where it could be useful to other people.

This came up recentish, and my first reaction is that this would be
between quite bothersome to handle, and not currently necessary. If
there's a downstream that is missing the perl modules I'd rather
request them to package the entire dpkg suite:

  
  

So I'm perhaps inclined to mark this as wontfix.

Thanks,
Guillem

Bug#821177: dpkg: please make dpkg perl libraries available on cpan

[Patrick Schoenfeld]

Source: dpkg
Severity: wishlist

Hi,

as of today it's not possible to use the perl-libraries in the Dpkg:: namespace 
on systems other then Debian (except someone packaged
them for the target system, like it has been done in Fedora).

Since the perl ecosystem does have it's own platform for modules with it's own
tooling (which we as a distribution happily benefit from, when packaing perl
modules), it would be very nice if Debian made their own libraries available on 
CPAN, too. 

Some Debian projects already do, unfortunately dpkg is a prime example where it 
could be useful to other people.

Best Regards,
Patrick

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information