Comments on: META.yml and Building RPMs

By: Dave Cross

Dave Cross — Thu, 18 Feb 2010 13:06:19 +0000

"Is there a better approach that we could reasonably have taken?" Yes, the approach suggested by jnareb here seems to me to be a good way round this issue.

By: chris.weyl

chris.weyl — Thu, 18 Feb 2010 05:07:28 +0000

“The Fedora RPM for this module takes a weird approach and makes JSON::XS a required dependency.”
How is this a “weird approach”? We needed to pick _something_ to use as a RPM dependency or perl-JSON-Any wouldn’t be guaranteed to be functional after installed, and JSON::XS was the fastest (at the time, anyways). Is there a better approach that we could reasonably have taken?

By: mirod.myopenid.com

mirod.myopenid.com — Wed, 10 Feb 2010 18:12:33 +0000

This seems to be somewhere where I have philosophical differences with the Fedora RPM packaging team. I believe that all of these modules should be seen as optional and there for shouldn't be listed as dependencies in the META.yml or the RPM. The Fedora team disagrees. They want each RPM to depend on all of the modules it needs in order to have as many features as possible, The Template-XML RPM therefore requires all of the XML processing modules I listed above. That seems wrong to me.

I don't think you and the Fedora Team have philosophical differences, you're just in 2 different places. The CPAN culture is to minimize dependencies. Or our users complain loudly. On the other hand, packagers control the repository, they have all the dependencies available, they can make sure they install properly, and they only have one shot at installing all that's needed for a package to work, unless they break it up in several packages. So it makes sense for them to err on the side of caution and include as many dependencies as possible. Or their users complain loudly.

That's especially true for RPMs, which don't seem to have (yet?) Debian's notion of optional but recommended dependencies.

Of course this doesn't apply to the cases you describe of alternate dependencies, but the current packaging systems would have to deal with those by creating alternate packages: Plack-Apache1 and Plack-Apache2 for example.

As a side note I am not sure the CPAN culture of minimizing dependencies is that healthy, and I like the fact that distributions don't hesitate to install plenty of code at once.

In the end, it doesn't really matter what option is chosen, users will still complain loudly ;--)

By: dagolden

dagolden — Wed, 10 Feb 2010 17:17:15 +0000

MYMETA was agreed upon at the Oslo Hackthon as part of the Oslo Consensus. It was called METALOCAL at the time, but subsequent discussions have renamed it MYMETA. The goal is to standardize how the toolchain can communicate post-configuration information instead of tools having to independently scrape Makefile.PL or _build/prereqs. It doesn't do anything new -- it just does it in a standard way. CPAN(PLUS) in Perl 5.10.1 already support MYMETA if it exists after configuration.

There was a proposal and review process for the definition of a CPAN Meta Spec 2.0. That has been postponed pending other high priority projects from the Pumpking and Perl NOC.

After 2.0 is finalized, I expect MYMETA to be implemented for ExtUtils::MakeMaker (and/or Module::Install), though CPAN Meta 2.0 will be represented in JSON, not YAML, due to inconsistencies in YAML implementation.

Hope that clarifies the current state of affairs..

-- dagolden

By: jquelin

jquelin — Wed, 10 Feb 2010 16:46:57 +0000

note also that mymeta.yml is not currently supported by eumm… this is enough to stop the idea of using mymeta (for now).

By: jnareb

jnareb — Wed, 10 Feb 2010 16:26:47 +0000

“Choose One” requirements
In RPM (and I guess also in dpkg format) the problem of depending on one of possible implementations is solved via metapackages. JSON::XS, JSON::DWIW and JSON would have ‘Provides: perl-JSON-implementation’ (or something like that), and JSON::Any would require such metapackage, i.e. ‘Requires: perl-JSON-implementation’.
This is used for example if given program requires web server, or mail daemon, but it doesn’t matter to it what exactly package / program is installed.
See subsection “Virtual Packages” in /usr/share/doc/rpm-*/dependencies

By: jquelin

jquelin — Wed, 10 Feb 2010 16:22:57 +0000

rpm supports optional dependencies with Suggests:
i’m currently facing the same problem for (official) mandriva rpms. i’m trying to move the prereqs extraction from using perl.req to a new perl.req-from-meta if meta.yml and/or meta.json is packaged (it defaults to using perl.req otherwise).
it’s a work in progress though…

By: nxadm

nxadm — Wed, 10 Feb 2010 15:42:42 +0000

Maybe irrelevant to the discussion, but debian/ubuntu dpkg format does have the “recommends” and the “depends on one of those” notion:
claudio@amsterdam:~$ apt-cache show libroxen-xmlutils |grep ‘Depends:’Depends: roxen3, pike (>= 0.6) | pike7 (>= 7.0.36) | pike7.2 | pike7.6
claudio@amsterdam:~$ apt-cache show libjson-perl |grep ‘Recommends:’
Recommends: libjson-xs-perl (>= 2.24)
claudio