Overview
found conflict of ctags-5.8-50.1.x86_64 with etags-27.1-4.1.x86_64 /etc/alternatives/ctags [mode mismatch: g -644 root:root, g l777 root:root] /etc/alternatives/ctags.1.gz [mode mismatch: g -644 root:root, g l777 root:root] /usr/bin/ctags [mode mismatch: g -644 root:root, g l777 root:root] /usr/share/man/man1/ctags.1.gz [mode mismatch: dg -644 root:root, dg l777 root:root]
How can a file that is not shipped conflict?
from your own spec:
%ghost %{_bindir}/ctags
%ghost %{_mandir}/man1/ctags.1%{ext_man}
%ghost %{_sysconfdir}/alternatives/ctags
%ghost %{_sysconfdir}/alternatives/ctags.1%{ext_man}
you still declare to own the files, and as such you can still conflict
The files don't ship so I don't see how they can actually conflict.
I installed both on my system for testing and there is indeed no conflict reported.
This is a false positive.
Please fix the test.
The problem looks like etags is shipping actual symlinks so the mode doesn't match.
rpm -qlp etags-27.1-4.1.x86_64.rpm ctags-5.8-49.d_t.2.x86_64.rpm -v lrwxrwxrwx 1 root root 22 Sep 18 16:33 /etc/alternatives/ctags -> ../../usr/bin/gnuctags lrwxrwxrwx 1 root root 38 Sep 18 16:33 /etc/alternatives/ctags.1.gz -> ../../usr/share/man/man1/gnuctags.1.gz lrwxrwxrwx 1 root root 23 Sep 18 16:33 /usr/bin/ctags -> /etc/alternatives/ctags -rwxr-xr-x 1 root root 150880 Sep 18 16:33 /usr/bin/etags -rwxr-xr-x 1 root root 151080 Sep 18 16:33 /usr/bin/gnuctags drwxr-xr-x 2 root root 0 Sep 18 16:34 /usr/share/doc/packages/etags -rw-r--r-- 1 root root 4139 Jul 27 23:21 /usr/share/doc/packages/etags/ETAGS.EBNF -rw-r--r-- 1 root root 2284 Jul 27 23:21 /usr/share/doc/packages/etags/ETAGS.README lrwxrwxrwx 1 root root 28 Sep 18 16:33 /usr/share/man/man1/ctags.1.gz -> /etc/alternatives/ctags.1.gz -rw-r--r-- 1 root root 4718 Sep 18 16:32 /usr/share/man/man1/etags.1.gz -rw-r--r-- 1 root root 37 Sep 18 16:32 /usr/share/man/man1/gnuctags.1.gz warning: ctags-5.8-49.d_t.2.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 498d5a23: NOKEY ---------- 1 root root 0 Jan 12 01:17 /etc/alternatives/ctags ---------- 1 root root 0 Jan 12 01:17 /etc/alternatives/ctags.1.gz ---------- 1 root root 0 Jan 12 01:17 /usr/bin/ctags -rwxr-xr-x 1 root root 301112 Jan 12 01:17 /usr/bin/ctags-exuberant drwxr-xr-x 2 root root 0 Jan 12 01:17 /usr/share/doc/packages/ctags -rw-r--r-- 1 root root 18007 Oct 12 2006 /usr/share/doc/packages/ctags/COPYING -rw-r--r-- 1 root root 14178 Oct 12 2006 /usr/share/doc/packages/ctags/EXTENDING.html -rw-r--r-- 1 root root 16979 Oct 12 2006 /usr/share/doc/packages/ctags/FAQ -rw-r--r-- 1 root root 2977 Apr 30 2008 /usr/share/doc/packages/ctags/README -rw-r--r-- 1 root root 16952 Jan 12 01:17 /usr/share/man/man1/ctags-exuberant.1.gz ---------- 1 root root 0 Jan 12 01:17 /usr/share/man/man1/ctags.1.gz
But those are ghosts as well, and don't conflict when actually installed with zypper.
Looks like false positive to me.
Also the openSUSE multiple versions packaging guide mandates that the alternatives files be included as ghosts. If they conflicted the multiple version scheme is unmaintainable.
Looks like it's broken in both packages
https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines
the %{_bindir} and %{_mandir} links are not to be ghosted but point to %{_sysconfig} for update alternatives. The links managed by update alternatives are to be ghosted and not shipped.
I'll fix both.
Request History
adamm created request
- Ship symlinks that are not to be ghosted in the first place
- Fix build on Tumbleweed - do not ship ghost symlinks.
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
RBrownSUSE added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:55"
RBrownSUSE accepted review
Picked "openSUSE:Factory:Staging:adi:55"
licensedigger accepted review
ok
jengelh accepted review
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:55"
dimstar_suse added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:165"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:adi:165"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:165"
dimstar_suse added as a reviewer
Being evaluated by staging project "openSUSE:Factory:Staging:adi:14"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:adi:14"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:adi:14"
dimstar_suse declined review
sr#891877 has newer source and is from the same project
dimstar_suse declined request
sr#891877 has newer source and is from the same project
adamm revoked request
ok
created request id 867418 for emacs that does similar changes
sr#867418 was revoked
@dimstar - created a new SR which does not conflict with emacs: https://build.opensuse.org/request/show/890336
Unfortunately, that has been ignored as of yet - @adamm, @michals
There was no conflict with emacs to start with.
The conflict was fabricates by a broken checker.
When the breakage was reported it was said that fabricating conflicts is what the checkers should do and it will not be fixed in the checker https://github.com/openSUSE/openSUSE-release-tools/issues/2439
There have been a number of requests trying to resolve this issue.
However, the alternatives system and the packaging guidelines for it require that packages share ghost files.
The checker fabricates conflicts of ghost files so these files must be identical between packages that provide an alternative (such as ctags and emacs).
I lack the context to judge if a SR to ctags alone is correct and should be accepted.
When a package installs a symlink pointing to itself (i.e. infinite resursion), that package is broken.
When both emacs/etags and ctags-exuberant install %{_bindir}/ctags without %ghost, that is a conflict.
The linked issues are not reachable from outside SUSE (build.suse.de or unsufficient permissions), so from my point of view these do not exist.
The problem persists for 3 months now. Doing nothing for 3 months is definitely no way forward.
Accepting the SR bears the risk of breaking a package which is already broken.
It was completely acceptable to ship ghost symlink pointing to itself before rpm 4.16. We have many packages that do it. I would not say it became broken overnight.
Initially %{_bindir}/ctags was a ghost symlink pointing to itself, and it was completely fine. Then they were removed, then added back as non-ghost, and maybe something more. There are several conflicting attempts at resolving what was initially a non-issue until multiple checker regressions.
I can understand that symlinks pointing to itself are not desirable but changing alternatives from something package-local as defined by the packaging guidelines to something distribution-global because of a broken checker is not. If the people maintaining the distribution still think that's the way to go then let them create SRs that solve the alternative problems in a distribution-global way and accept them as well.
Also I do not know which linked issue not accessible to you you are talking about. The only issue I linked to is on github in openSUSE org.
Just follow the link, no information but two inaccessible links.
So, are you going to take action? Or will you leave this package broken for another 3 months?
Your SR does not follow https://en.opensuse.org/openSUSE:Packaging_Multiple_Version_guidelines by shipping the alternative symlinks as ghosts.
Unfortunately, with checkers that check conflicts of ghost files the guideline must be followed to the letter if we are to stand a chance to get non-conflicting packages.
Nevermind, that's broken. If two packages share an identical file as advised by the guide it works for rpm but there is another checker that will reject that.
And it creates a dangling symlink which IIRC is also rejected.
If packagers cannot follow the guide and have to creatively add the missing pieces then we cannot hope that two independent packages install the same alternatives symlinks and satisfy the checkers.