BackupPC V4 From Epel

Home » CentOS » BackupPC V4 From Epel
CentOS 3 Comments

Hello Everyone,

Has anyone tried to install BackupPC v4 on CentOS 8 from epel? I just did and this happened:

[root@resurrect ~]# dnf –enablerepo epel install BackupPC
Last metadata expiration check: 0:18:41 ago on Tue 15 Oct 2019 08:03:59 PM EDT. Error:
Problem: conflicting requests
– nothing provides par2cmdline needed by BackupPC-4.3.1-2.el8.x86_64
– nothing provides perl(Net::FTP::AutoReconnect) needed by BackupPC-4.3.1-2.el8.x86_64
– nothing provides perl(Net::FTP::RetrHandle) needed by BackupPC-4.3.1-2.el8.x86_64
– nothing provides perl(Time::ParseDate) needed by BackupPC-4.3.1-2.el8.x86_64
– nothing provides perl(XML::RSS) needed by BackupPC-4.3.1-2.el8.x86_64
– nothing provides perl-Time-modules needed by BackupPC-4.3.1-2.el8.x86_64
(try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

If that didn’t come out too nice, here’s a pastebin link:

https://pastebin.com/HgjAQmvV

I’ve checked all the disabled repos on my system and none of them have those packages. Is this just a case of the dependencies not being built yet?

3 thoughts on - BackupPC V4 From Epel

  • Hi Ranbir,

    as you said this could be a list of deps not yet released. If your machine is a “testing machine” you can try to enable epel-testing and epel-playground and check if those deps are in those supplementary repos. Caution because they are testing repos so if you need to use on production wait releases.

    Hope that helps.

  • It seems EPEL doesn’t use a repoclosure test when pushing from testing to stable. Let me just take one simple example : I recently asked a pkg to be built for epel 8 (see https://bugzilla.redhat.com/show_bug.cgi?id=1755787)

    So that package itself was able to be built, and despite the fact that it was mentioned that it has some Requires: issues (see two other reports in the original one), it was still pushed from -testing to stable , so actually you can see it :

    Available Packages lollypop.noarch 1.1.97.3-1.el8
    epel

    But it’s not installable (obviously) :
    Problem: conflicting requests
    – nothing provides kid3-common needed by lollypop-1.1.97.3-1.el8.noarch
    – nothing provides python3-pylast needed by lollypop-1.1.97.3-1.el8.noarch

    Stephen (smooge) would probably be able to comment if that would be possible for Epel to have some gating from -testing to stable (like a simple repoclosure test) to see if packages pushed to stable can be installable (and so satisfied deps in stable repo too)

  • Sadly repoclosure would only work for EPEL-6 and 7 . I think it stopped working after some changes were made to rpm after Fedora 21 or so.. [Try running repoclosure on CentOS-8:

    package: systemd-udev-239-13.el8.x86_64 from BaseOS
    unresolved deps:
    systemd(x86-64) = 239-13.el8
    package: systemd-udev-239-13.el8_0.3.i686 from BaseOS
    unresolved deps:
    systemd(x86-32) = 239-13.el8_0.3
    package: systemd-udev-239-13.el8_0.3.x86_64 from BaseOS
    unresolved deps:
    systemd(x86-64) = 239-13.el8_0.3
    package: valgrind-devel-1:3.14.0-9.el8.i686 from AppStream
    unresolved deps:
    valgrind = 1:3.14.0-9.el8
    package: valgrind-devel-1:3.14.0-9.el8.x86_64 from AppStream
    unresolved deps:
    valgrind = 1:3.14.0-9.el8

    … it goes on and on.]

    A new repoclosure tool would need to be written, then integrating it with I think bodhi would be needed.