#3375 Issue open: unpacking of archive failed on file /usr/share/rear/skel/default/var/run: cpio: File from package already exists as a directory in system

thomasmerz opened issue at 2025-01-02 09:39:

  • ReaR version ("/usr/sbin/rear -V"):
    Relax-and-Recover 2.8 / 2024-12-19

  • If your ReaR version is not the current version, explain why you can't upgrade:
    See issue 😉

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):

LSB Version: core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0.fake-amd64:desktop-4.0.fake-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0.fake-amd64:graphics-4.0.fake-noarch
Distributor ID: openSUSE
Description: openSUSE Leap 15.5
Release: 15.5
Codename: n/a

  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):
    PC, Baremetal

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    x86

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    UEFI, GRUB

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local disk(s)

  • Description of the issue (ideally so that others can reproduce it):
    When updating ReaR on OpenSUSE from rear-2.7-2.x86_64 to rear-2.8-3.x86_64 it fails with:

warning: /etc/rear/local.conf created as /etc/rear/local.conf.rpmnew
error: unpacking of archive failed on file /usr/share/rear/skel/default/var/run: cpio: File from package already exists as a directory in system
error: rear-2.8-3.x86_64: install failed
error: rear-2.7-2.x86_64: erase skipped

  • Workaround, if any:
    I fixed it by sudo mv /usr/share/rear/skel/default/var/run /usr/share/rear/skel/default/var/run.old but I wanted to let you know about this bug.

lzaoral commented at 2025-01-03 11:52:

I have also hit the same issue when packaging ReaR 2.8 for Fedora. It is caused by https://github.com/rear/rear/commit/b838a352136811900511a209d06c809ce552e636 and according to Fedora packaging docs must be solved on the specfile level: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/

hpannenb commented at 2025-01-03 13:51:

Issue is identical on a RHEL 7.9 system when I try to update/install ReaR 2.8. Error retrieved with yum install...:

Transaction check error:
  file /usr/share/rear/skel/default/var/run from install of rear-2.8-3.el7.x86_64 conflicts with file from package rear-2.7-2.el7.x86_64

Error Summary
-------------

Edit: Applying the workaround of @thomasmerz is solving the error on my system as well.

pcahyna commented at 2025-01-03 14:49:

IMO this should be solved in the sources, as otherwise all RPM-using distributions will have to solve the same problem. Of course we would then have to invent another solution to the problem that was solved by https://github.com/rear/rear/commit/b838a352136811900511a209d06c809ce552e636

jsmeix commented at 2025-01-07 09:57:

Because the root cause is "a known limitation with RPM", cf.
https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/
I think it should be fixed in RPM packaging
(i.e. where the root cause is)
and not in the ReaR sources
where we would have to do a ReaR 2.8.1 release
(I myself won't do the actual ReaR 2.8.1 release process)
and then all RPM-using distributions would have to
upgrade from ReaR 2.8 to ReaR 2.8.1 which is probably
not less work than fixing the existing ReaR 2.8 RPM packaging.

pcahyna commented at 2025-01-07 10:36:

I have a fix almost ready - it installs the problematic symlink inside a tarball.

pcahyna commented at 2025-01-07 10:39:

@jsmeix I think it is easier for all the distros to pick the new sources than to apply a fix to their spec file more or less independently (assuming that distros generally do not use the upstream spec).
Moreover a "fix" in RPM packaging is more a workaround than a real fix, because a package downgrade will still be broken (a similar workaround would have to be applied to the old version back in time), which seems not ideal to me if the problem is solvable in any other way.

pcahyna commented at 2025-01-07 10:41:

I can do a 2.8.1 release if we agree on it.


[Export of Github issue for rear/rear.]