It should be handled by dnf as it was in yum.

https://github.com/openSUSE/libsolv/issues/149 requests this functionality in libsolv and even has some short-term solution to do in libdnf.

So I would vote that there is nothing to do from FPC.

I'm tagging this for meeting on this Thursday. @jmracek would be good if you will be present there to describe problem.

Thanks Igor for remind me the issue. But the issue is there for more than 2 years and only writing the issue doesn't solve it as you can see. We have to push it little bit more further.

But not by "fixing" it by adding nonsensical conflict annotations to all packages that might be potentially multilib.

While moving architecture-independent files into noarch packages looks reasonable we have a contradicting rule in the guidelines.

Also imagine a standard devel package:

%{_libdir}/libfoo.so -> %{_libdir}/libfoo.so.1  fullarch
%{_libdir}/pkgconfig/foo.pc                              fullarch
%{_includedir}/foo.h                                          noarch
%{_mandir}/man3/libfoo.3*                              noarch
%{_bindir}/foo-config                                        fullarch
%doc example                                                     noarch

Are we going to create for all of these packages a special devel-noarch subpackage and moving noarch files there?

And what with the remaining fullarch packages? Are we going to add into each of them the reflexive Conflicts?

Wouldn't be more reasonable to teach rpmbuild to add the reflexive Conflicts automatically into every binary package? (Like Provides for NEVRA are autoadded.)

Wait. What about multiversion packages like "kernel"? We would need a new knob to explain to rpmbuild that kernel must still allow installing multiple package versions and not to auto-add the reflexive Conflicts.

If we need to change something, we should either patch rpmbuild or DNF. I don't believe it makes sense to add a clutter into every spec file.

Let me point it this way:
1. At the present time the problem cannot be solved on DNF side. The required functionality is still missing in solver - libsolv that is maintained by SUSE. There is also no plan to implement it (see: https://github.com/openSUSE/libsolv/issues/149)
2. But the issue can be solved from packaging side. Conflicts work well and they are supported for really long long time and everywhere.

The good question is what can be done right now?

At the present time the problem cannot be solved on DNF side

That's not entirely true, it can be worked out with SOLVER_NOAUTOSET

The required functionality is still missing in solver - libsolv that is maintained by SUSE

You know that it is open source project and you can send patch to it, right?

But the issue can be solved from packaging side. Conflicts work well and they are supported for really long long time and everywhere

Asking maintainers to do that seems to be really bad idea because they would need to fix every single package. They will rather give up on supporting multilib.

Yeah, adding conflict to itself to every package that can be potentially multilib is ulitmately the worst fix possible. We are talking about hundreds of packages here. I would even say that keeping the unfixed status quo or dropping multilib support altogether would be better.

For reference the packaging guidelines say that conflicts are a last resort, and that they must be explicit: https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/

So any implicit conflicts are already violations of the guidelines. The original request indicates "but in Fedora Packaging Guidelines the problem is not mentioned as an issue", so I guess the request would be that we add specific mention of the issues into the section on devel packages (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages) or to add a new section directly relating to multilib packages. I'm just not sure what either of these would say.

So any implicit conflicts are already violations of the guidelines

Well, there are dependency generators... Which can generate conflicts and obsoletes ;)

I didn't realize they could generate anything other than plain Requires:. But even then, I'm not sure that a dep generator would have enough knowledge to even know that a package would end up being multilib, much less what other packages it should be in conflict with.

@tibbs Please note that there is no implicit or explicit conflict here. This is just a deficiency of the update transaction solver that it does not know that it must update both arch variants of a multilib package in sync.

So no, the packages do not violate any packaging guidelines. This is a clear misunderstanding.

Then lets talk about recommendation to move shared files into noarch packages.
Why:
1. It solves file conflict issue
2. Ensure that shared files created even from same source will have same checksums. I believed that shared files generated on 32 bit and 64 bit arch could differ in checksums.
3. Force to upgrade multilib packages synchronously
4. Change only applies for multilib packages with shared files - more selective approach but solves issue completely

@ignatenkobrain I am sorry but I cannot attend the next meeting.

I hope FPC will not force changes in hundreds of packages due to DNF deficiency that can be fixed in it.

Then lets talk about recommendation to move shared files into noarch packages.
Why:
1. It solves file conflict issue

Only for packages whose fullarch file subset is installed to an arch-specific path (%{_libdir}). Other packages (e.g. having ELFs in %{_bindir}) will remain conflicting.

1. Change only applies for multilib packages with shared files - more selective approach but solves issue completely

Packagers do not not know which packages are multilib and which are not. A multilib property is defined by relengs when composing a distribution and if nothing has changed, it is defined by a set of regular expressions matching package names and a large whitelist and a blacklist. Relengs do not provide any feedback to packagers that they made or unmade a multilib status from their package.

It doesn't help that the initial message appears to have very little to do with what seems to be the actual topic of discussion here.

Personally I agree with @ignatenkobrain that this isn't really an issue for the FPC to address. I think this should be fixed in the proper place (dnf, the dependency solver, whatever). I don't think the problem is one that could be generally solved by adding more to the packaging guidelines in any case, and I don't see the value in trying to force the rework of every package which happens to be declared multilib. I'd wager that in many cases, the maintainers would prefer that their packages not be multilib but it's not something they can control.

That said, if separately packaging the common files separately somehow improves the user experience or provides some other benefit besides just working around , and if someone wants to draft a small bit of text we could add in the appropriate place to encourage that, then I don't see why we wouldn't consider it.

We talked about this at this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-11-29/fpc.2018-11-29-17.00.txt

• #834 Multilib file conflict (geppetto, 17:17:18)
• Main problem is that DNF is much happier than yum to let foo.x86_64
  and foo.i686 be different versions (geppetto, 17:22:55)
• Working around this in packages is generally agreed to be insane
  (geppetto, 17:23:23)
• The yum option is "protected_multilib". (tibbs, 17:29:11)
• ACTION: There's nothing useful FPC can do here, there are multiple
  options to fix the dnf/rpm stack and we encourage the developers to
  implement one (geppetto, 17:30:22)