I have an rpm package I built which depends on perl. When I try to install this package it fails:

$ rpm -ivh <package-y>
error: Failed dependencies:
    perl is needed by package-y.x86_64

If I run dnf info perl it shows that perl is not installed but I am able to find perl on my system:

which perl
perl: /usr/bin/perl /opt/lampp/bin/perl /usr/share/man/man1/perl.1.gz

And checking for perl's version:

$ perl --version

This is perl 5, version 26, subversion 2 (v5.26.2) built for x86_64-linux-thread-multi
(with 47 registered patches, see perl -V for more detail)

Copyright 1987-2018, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl".  If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

It seems that perl is installed by default on my system (fedora) but why does the package manager (dnf or rpm) not recognise it?

  • 1
    If the metadata of a package says it depends on perl, it means you must have on your system a package that is either named exactly like perl-<version>.<architecture> or has Provides: perl in its metadata. What does the rpm -q perl say? Or rpm -qf /usr/bin/perl?
    – telcoM
    Jul 4, 2018 at 17:38
  • So you are saying that I must have a .rpm package named perl in order for perl not to be classed as a missing dependency? Isn't this odd when perl is installed by default on my system. And are you suggesting I create a dummy package named perl? What if I dnf install perl, will it cause conflicts with my pre-installed default perl?
    – bit
    Jul 4, 2018 at 17:44
  • Or a package that includes Provides: perl in its RPM package metadata, yes. rpm -qf /usr/bin/perl should tell you the actual name of your current perl RPM, and rpm -q --provides <package name> will tell the Provides keywords it has. I would not suggest a solution before knowing what the initial state actually is.
    – telcoM
    Jul 4, 2018 at 17:50
  • $ rpm -q perl package perl is not installed $ rpm -qf /usr/bin/perl perl-interpreter-5.26.2-412.fc28.x86_64. Yes, more info is needed for a solution. Is rpm -q --provides for the package which needs perls as a dependency?
    – bit
    Jul 4, 2018 at 17:55

1 Answer 1


Specifying dependencies to something like Perl can be very complex. For example, when your package-y says it requires perl, does it mean Perl 5.x or Perl 6.x? Does it need a specific minor version of Perl 5.x? Or would an ancient Perl 4.x be enough for it?

Here's the part of Fedora Packaging Guidelines that concerns Perl. As you can see, it is rather complicated. It looks like your package-y is not following those guidelines. Is it intended for Fedora specifically, or is it packaged for some other random distribution?

The best way to fix it without repackaging package-y would be to find out what specific requirements your package-y actually has for Perl, then create a dummy package with a name like dependencies-for-package-y.rpm with both Provides: perl (to allow the dummy package to satisfy the requirements of package-y) and at least Requires: perl(:VERSION) >= <minimum required Perl version for package-y> (to supply the information of package-y's actual requirements to the package manager).

If your package-y includes pre-compiled Perl modules, or links into libperl.so, the dummy package should also have the appropriate Requires: perl(:MODULE_COMPAT_<version number>) keyword. That way, if your current Perl is updated in a way that breaks module compatibility e.g. because of a security issue, your package manager will tell you that you must either also update package-y, remove it, or defer updating your Perl because updating it would break package-y.

Your current /usr/bin/perl is actually supplied by a package named perl-interpreter. You can see the Requires and Provides keywords that package has in rpmfind.net.

  • great answer. Yes, dnf info perl-interpreter shows it is in fact the perl that I have installed. Did I mention when I say built an rpm package, I mean using a program called fpm not using something like rpmbuild. Based on this, it is not too difficult to rebuild the package but as a long term solution may be there's a better solution?
    – bit
    Jul 4, 2018 at 18:33
  • The absolute best solution would be repackaging package-y so that has its dependencies specified according to the Fedora Packaging Guidelines for Perl. I missed the fact that you said you had actually built package-y. You might be able to "disassemble" the package generated with fpm, make the necessary dependency modifications and then rebuild it with rpmbuild.
    – telcoM
    Jul 4, 2018 at 18:52
  • That was exactly what I did, repackaged with perl-interpreter replacing perl as one of the dependencies, and it worked. I'm not familiar with rpmbuild but now I know a bit about it I may look into using it. What would you say is the difference between rpmbuild and fpm when generating rpm packages?
    – bit
    Jul 4, 2018 at 20:33
  • rpmbuild is the full-featured standard tool that is specific for rpm packages. It would be the "native" tool for rpm. fpm attempts to be an universal automated easy tool for multiple packaging formats, but its automation seems to currently fall somewhat short of the goal, at least for Perl packages. Reading its feature list, it seems to me its developer has provided some advanced functionality for packaging Python software, but not (yet?) for Perl.
    – telcoM
    Jul 5, 2018 at 13:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .