FAQ
16. Binary Package Dependencies

Proposal:

Add a binary dependency keyword to be optionally resolved by the shell. eg.

binary_requires:
- linux-debian:
libgif4-dev: 4.1.6
- linux-ubuntu:
libgif4-dev: 4.1.6
- linux-redhat:
giflib-devel: 4.1.6
- freebsd-ports:
giflib: 4.1.6
- freebsd-pkg:
giflib4: 4.1.6

The aim is for use by Alien:: namespace modules to declare a
dependency that would allow them to detect their desired non-Perl
dependency without installing a copy of the code involved that isn't
tracked by the system package manager (and hence isn't subject to
security updates.

I don't expect immediate implementation by CPAN/CPANPLUS, but it
provides a structure where extensions to either can find the
information needed to install those packages if the user desires.

If an Alien::* module's configuration (Makefile.PL/Build.PL) were
started without the packages installed, then either the user chose not
to install the packages, or no package was found for the given
platform. The Alien::* could then install from source (or fail.)

A Makefile.PL or Build.PL doesn't necessarily have the information
needed to know whether to install a package, while CPAN/CPANPLUS may,
especially given the possibility of extra configuration (o conf
binary_requires on|off).

One weakness with the above is the lack of alternatives, a few years ago we
might have been satified by either libgif or libungif (Tonyc)

Comments:

* The biggest challenge with this proposal is the need for a
target-agnostic specifier. If a truly portable method exists for defining
"libgif version 4.1.6 or better" then you don't need to say which
packages are needed, as the resolution of a package from the arbitrary
identifier can be solved independently. The need for massive amounts of
consulting with other communities to achieve some useful consensus on
identifiers is the biggest challenge for this proposal. --Adam K

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 1:13 pm
    * David Golden [2009-10-09T07:49:40]
    16. Binary Package Dependencies
    No vote, but highly dubious that it could be done in a way we won't regret
    later.

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 1:59 pm

    On Oct 9, 2009, at 8:12 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:49:40]
    16. Binary Package Dependencies
    No vote, but highly dubious that it could be done in a way we won't
    regret
    later.
    I agree.

    Graham.
  • Steffen Mueller at Oct 9, 2009 at 2:27 pm

    David Golden wrote:
    16. Binary Package Dependencies
    If we could get this right, I'd give all my votes for this. I know that
    at least Adam and I had been thinking hard about this kind of thing in a
    different context a few years back. It's utterly hard to get right if at
    all possible.

    Sadly, -1.

    Steffen
  • Tony Cook at Oct 11, 2009 at 11:11 pm

    On Fri, Oct 09, 2009 at 04:27:03PM +0200, Steffen Mueller wrote:
    David Golden wrote:
    16. Binary Package Dependencies
    If we could get this right, I'd give all my votes for this. I know that
    at least Adam and I had been thinking hard about this kind of thing in a
    different context a few years back. It's utterly hard to get right if at
    all possible.

    Sadly, -1.
    Does anyone have a pointer to previous discussion of this type of
    mechanism?

    Tony
  • David Golden at Oct 9, 2009 at 9:20 pm

    On Fri, Oct 9, 2009 at 7:49 AM, David Golden wrote:
    16. Binary Package Dependencies

    Proposal:

    Add a binary dependency keyword to be optionally resolved by the shell. eg.
    -1. I think this will be messy and prone to breakage.

    -- David
  • Zbigniew Lukasiak at Oct 22, 2009 at 8:08 am
    Hi there,

    I've noticed two reactions to this proposal: it is great if it could
    be done right and it is currently too difficult. This leads me to
    following: how about a lib_requires (or requires_lib) - with identical
    semantics as Devel::CheckLib. Now Devel::CheckLib is used in
    Makefile.PL - but it means that this information about library
    prerequisites is not available to tools analysing the source code like
    installation tools, cpan search, dependency viewers or PAR.
    lib_requires would be kind of half step of the original proposal -
    after it is accommodated we could think about loading another external
    mapping between the library name and the OS package. The advantage of
    this is that the semantics can be defined quite precisely if only
    Devel::CheckLib has clear semantics, but it is already a recommended
    tool so I assume that it is.

    I know I am a bit late to the party - so I don't insist on doing that
    in this current cycle - but I would like to put this under discussion
    and perhaps include it in the next change cycle.
  • David Golden at Oct 22, 2009 at 11:31 am

    On Thu, Oct 22, 2009 at 4:08 AM, Zbigniew Lukasiak wrote:
    Hi there,

    I've noticed two reactions to this proposal: it is great if it could
    be done right and it is currently too difficult.  This leads me to
    following: how about a lib_requires (or requires_lib) - with identical
    semantics as Devel::CheckLib.  Now Devel::CheckLib is used in
    Makefile.PL - but it means that this information about library
    prerequisites is not available to tools analysing the source code like
    installation tools, cpan search, dependency viewers or PAR.
    lib_requires would be kind of half step of the original proposal -
    after it is accommodated we could think about loading another external
    mapping between the library name and the OS package.  The advantage of
    this is that the semantics can be defined quite precisely if only
    Devel::CheckLib has clear semantics, but it is already a recommended
    tool so I assume that it is.

    I know I am a bit late to the party - so I don't insist on doing that
    in this current cycle - but I would like to put this under discussion
    and perhaps include it in the next change cycle.
    I like this idea. (David Cantrell, are you on this list? Thoughts?).
    I'm open to further discussion for this cycle if the semantics are
    clear enough.

    Even if not for this cycle, I do want to keep it on the list for next round.

    David
  • David Cantrell at Oct 22, 2009 at 1:03 pm

    David Golden wrote:
    On Thu, Oct 22, 2009 at 4:08 AM, Zbigniew Lukasiak wrote:
    I've noticed two reactions to this proposal: it is great if it could
    be done right and it is currently too difficult.  This leads me to
    following: how about a lib_requires (or requires_lib) - with identical
    semantics as Devel::CheckLib...
    I like this idea. (David Cantrell, are you on this list? Thoughts?).
    I am now :-)

    The relevant Devel::CheckLib parameters are:

    lib
    header (this should probably be renamed to inc, with an alias for
    sdrawkcab compatibility)

    Note that as well as having a library, you need to have the C header
    file so you can build stuff against it. Also, in things like Debian,
    those tend to be in seperate packages.

    function (so far only in the latest dev version, which doesn't work on
    Windows; there's a patch in RT which I've not yet applied)

    'function' is so that you can provide the body of a C function to check
    things like "is the library a high enough version" or "does it contain
    function foo()":

    function => 'foo();if(libversion() > 5) return 0; else return 1;'

    For the purposes of META.yml you probably want to instead specify that
    as something like:

    providesfunctions: [list of functions]
    libversion:
    version: > 5
    howtofind: libversion()

    so that the information is available in a more easily parsed form, but
    you could also build the relevant C snippet from the info. This would
    also mean that that info could go into META.yml independent of me
    getting round to fixing my Windows bug.

    There's also libpath and incpath, but I imagine those aren't relevant
    here.

    --
    David Cantrell | Godless Liberal Elitist

    It wouldn't hurt to think like a serial killer every so often.
    Purely for purposes of prevention, of course.
  • Damyan Ivanov at Oct 22, 2009 at 2:42 pm
    -=| David Cantrell, Thu, Oct 22, 2009 at 02:03:50PM +0100 |=-
    lib
    header (this should probably be renamed to inc, with an alias for
    sdrawkcab compatibility)

    Note that as well as having a library, you need to have the C header
    file so you can build stuff against it. Also, in things like Debian,
    those tend to be in seperate packages.
    Note that the libfoo-dev packages (the ones with C header files) are
    required to depend on the relevant library package. At least on
    Debian.

    --
    dam
  • Slaven Rezic at Nov 1, 2009 at 6:51 pm

    David Golden wrote:
    16. Binary Package Dependencies
    -1

    However, I like the idea of a data structure describing external
    dependencies. But I would like to locate this into a generic Alien
    interface/driver module family. This one knows about
    OS/distribution-specific installation procedures (yum, apt-get/aptitude,
    portinstall/pkg_add/... ...), knows about user preferences (useful when
    OS/distribution has different package installers to choose from), and
    knows how to map the describing data structure to the
    OS/distribution-specific package names. Also it should have a
    description how to install the library/binary from scratch, that is, how
    to fetch, configure, build, and install (similar to the FreeBSD port or
    Gentoo portage system) (because such a description could be OS-specific,
    it should be possible to create it dynamically).

    Once such a system stabilizes it could find its way into the META spec,
    and the required generic Alien driver module into the Perl core.

    Regards,
    Slaven
  • Adam Kennedy at Nov 2, 2009 at 10:48 pm
    Opposed, this is not the right forum to be attempting sweeping
    language/library solutions of this kind (yet).

    I have an potential alternative solution to this problem, outside of
    the score of META.yml, that I'd like to see attempted first.

    -1

    Adam K

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:50a
activeNov 2, '09 at 10:48p
posts12
users10
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase