Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
Those releases are something like ten years out of support by now. If you need it, the patch is out there if you need it. That's open-source power for you. Now, this issue here is about a very specific case regarding the symlink detection logic in rpm, that actually has zero to do with the old Fedora hacks. So I'm going to hide this side-discussion as off-topic, which it is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1852042989 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
But you shipped it and then unshipped it, so now you can't even do mock or chroot builds of those releases. If handling stuff like this is properly fixed in RPM, there's no reason to not have some way to emit those `rpmlib()` capabilities either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1851936907 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
Eek, no. That Fedora specific hack is not coming anywhere near upstream. Sorry but I don't have a whole lot of sympathy for the use-case of installing Fedora 17 by current rpm versions... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1851876299 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
If we can solve this somehow, can we also bring in the old `rpmlib()` things from [this patch](https://src.fedoraproject.org/rpms/rpm/blob/f20/f/rpm-4.10.90-rpmlib-filesystem-check.patch) so that dnf installroot installs for affected distributions don't fail like this? ``` Running transaction check Error: transaction check vs depsolve: rpmlib(X-CheckUnifiedSystemdir) is needed by setup-2.8.48-1.fc17.noarch rpmlib(X-CheckUnifiedSystemdir) is needed by filesystem-3-2.fc17.x86_64 To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'. You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue. ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1830850932 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
There's also another BZ report of the same (including a reproducer which is almost identical to the one above): https://bugzilla.redhat.com/show_bug.cgi?id=1835424 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1821095859 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
This indeed looks like a dupe of
https://bugzilla.redhat.com/show_bug.cgi?id=1936422 which #1684 was attempting
to fix. The actual, real transaction (assuming that a `%pretrans` scriptlet
removing the old symlink is present) does the right thing, this is just about
the *test* transaction (which DNF/YUM perform) where it fails.
A minimal package reproducing the issue:
```
%bcond_with new
Name: symlink
%if %{with new}
Version: 2
%else
Version: 1
%endif
Release: 1%{?dist}
Summary: Symlink conflict test
License: GPL
%description
%{summary}.
%if %{with new}
%pretrans -p
path = "/opt/symlink/bar"
st = posix.stat(path)
if st and st.type == "link" then
os.remove(path)
end
%endif
%prep
%build
%install
mkdir -p %{buildroot}/opt/symlink/foo
echo hello > %{buildroot}/opt/symlink/foo/blah
%if %{with new}
mkdir -p %{buildroot}/opt/symlink/bar
echo new > %{buildroot}/opt/symlink/bar/blah
%else
ln -s foo %{buildroot}/opt/symlink/bar
%endif
%files
/opt/symlink
```
Usage:
```
$ rpmbuild -bb /path/to/symlink.spec # builds symlink-1-1 package
$ rpmbuild -bb --with new /path/to/symlink.spec # builds symlink-2-1 package
$ rpm -Uhv /path/to/symlink-1-1.rpm
$ rpm -Uhv --test /path/to/symlink-2-1.rpm # this should fail
$ rpm -Uhv /path/to/symlink-2-1.rpm # this should work
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1798570225
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
Yes, this issue is still present on master, the associated logic hasn't been changed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1798450397 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
In the latest version, the RPM file installation is reconstructed. Can you confirm whether the latest version involves this problem or provide detailed reproduction steps. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-1340586937 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
This is a long-standing issue with file<->directory replacement. There's some guidelines on how to work around the issue here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458#issuecomment-749059651___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] File conflicts: Symlinked directories -> same file replaced by real directories -> unique files (#1458)
RPM Version: 4.13.1 (also recreated in 4.15.1) Hi, my name is Mark Irish and I am on a team of developers that creates and distributes RPMs for open-source software on IBM i. In our distribution of RPM itself, we are trying to replace generic platform macros shared between all versions/releases of our system with release-specific macro files. ### The issue we are running into: Previously, our `rpm.spec` handled platform macros by creating a symlink from every version/release to a common directory that stored the `macros` file. This meant that `.../rpm/platform/ppc-ibmi7.1/`, `.../rpm/platform/ppc-ibmi7.2/`, and `.../rpm/platform/ppc-ibmi7.3/` all were symlinked to `.../rpm/platform/ppc-ibmi`, and this latter directory held the `macros` file. That worked well, but now we want to enable release-specific flags in our macros. However, when trying to replace the 3 macro "files" that were all the same (because they were symlinked to the same directory) with 3 different macro files in non-symlinked directories, the 2nd and 3rd file throw a `conflicts between attempted installs` error: ``` Transaction Check Error: file /QOpenSys/pkgs/lib/rpm-test/platform/ppc-ibmi7.2/macros conflicts between attempted installs of rpm-test-0.0.0-1.ppc64 and rpm-test-0.0.0-1.ppc64 file /QOpenSys/pkgs/lib/rpm-test/platform/ppc-ibmi7.3/macros conflicts between attempted installs of rpm-test-0.0.0-1.ppc64 and rpm-test-0.0.0-1.ppc64 ``` I don't believe this is an issue with symlinked directories. **We are aware that there is some lua magic that has to be done to convert symlinks to directories.** [We have followed the script here](https://fedoraproject.org/wiki/Packaging:Directory_Replacement#:~:text=Due%20to%20a%20known%20limitation,trying%20to%20install%20the%20package.), and it has fixed previous errors that we were encountering. The issue seems to be RPM expecting any change to `.../rpm/platform/ppc-ibmi7.1/macros`, `.../rpm/platform/ppc-ibmi7.2/macros`, and `.../rpm/platform/ppc-ibmi7.3/macros` to be uniform: It doesn't complain about `7.1`, the first directory that changes to a new file, only about `7.2` and `7.3`. This also explains why the error notes of `conflicts between attempted installs of` the same version. **I am able to provide 2 minimal spec files that recreate this issue.** ### The question: Is this a bug in RPM? It seems possible that this is a strange edge case that wasn't considered, though the area of the code notes https://github.com/rpm-software-management/rpm/blob/4cbdd7c94071f52dfe64466df80e859193d89d89/lib/transaction.c#L628 Is there any RPM or lua magic that can be done to resolve these errors, similar to the lua script to resolve? Possibly create an intermediary release that somehow fixes the issue and allows the next release to replace the single `macros` file with multiple unique files? I think a solution like `https://github.com/rpm-software-management/rpm/issues/1118` would work, but again that upgrade would have to be an intermediary step, as our issue is errors using RPM to upgrade RPM. Thank you. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1458___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
