Description of problem: bash is provided both as i686 and x86_64 package in the x86_64 repository. This is because it produces a -devel sub-package which trigger the multilibs dependencies on the binary bash. Version-Release number of selected component (if applicable): bash-5.0.7-3.fc32 (all versions up to rawhide) Actually f29 isn't affected so the bug might have been introduced later. How reproducible: dnf install bash (with multilib_policy=all in yum.conf) (or dnf install bash.i686) Actual results: /usr/bin/bashbug is failing to install because it's different on i686 build and x86_64 one. Expected results: No installation issue with multilib_policy=all Additional info: I would like to have this fixed for f31+ at least. I expect few possible solutions: 1/ Easiest is probably to drop the _isa require from the devel sub-package on main 2/ Rename (drop ?) the -devel subpackage. I don't see where it's been used for as there are header will no library (and no users). But it could be renamed from -devel to -header to avoid the multilib computation. 3/ Use alternatives for bashbug
According to changelog mpibash may uses the headers, but this last isn't provided as multilibs, so all solutions still seem valid. PR with 1/ implemented https://src.fedoraproject.org/rpms/bash/pull-request/16
I may nominate this bug as a f31 blocker given that it may affect the ability to use multilib_policy=all for the whole f31+ lifetime.
Proposed as a Blocker for 31-final by Fedora user kwizart using the blocker tracking app because: bash.i686 is provided in the x86_64 by error This trigger an installation issue if the distro is configured yum.conf with: multilib_policy=all That's because the bashbug is different on i686 and x86_64 Alternative is to exclude the i686 build from x86_64 in a multilib blacklist.
The isa requires is not present on f29 branch but was forwarded in the f30 timeframe.
Isa require was introduced in the following commit: commit 91692f161e3e827ef82b7381b4cea1654cca7fd3 Author: Siteshwar Vashisht <svashisht> Date: Wed Feb 13 17:57:17 2019 +0100
On f29 the bash.i686 isn't provided but the bash-devel.i686 is (but is not installable along the x86_64 package). So I think renaming the -devel to -headers is probably the long term fix. (using obsoletes/provides for devel will not trigger the multilibs script).
I've sent an alternate PR with drop_devel (actually rename) implementing /2 https://src.fedoraproject.org/rpms/bash/pull-request/17 Koji scratch build for f31 https://koji.fedoraproject.org/koji/taskinfo?taskID=38306246
(In reply to Nicolas Chauvet (kwizart) from comment #0) > Actually f29 isn't affected so the bug might have been introduced later. I am not able to install bash-devel.i686 and bash-devel.x86_64 at the same time on f29: Error: Transaction check error: file /usr/include/bash/config.h from install of bash-devel-4.4.23-6.fc29.i686 conflicts with file from package bash-devel-4.4.23-6.fc29.x86_64
(In reply to Kamil Dudka from comment #8) > (In reply to Nicolas Chauvet (kwizart) from comment #0) > > Actually f29 isn't affected so the bug might have been introduced later. > > I am not able to install bash-devel.i686 and bash-devel.x86_64 at the same > time on f29: Indeed, confirmed in c#6, fixed in c#7
New PR that does not handle the bash.i686 -> x86_64 transition I expect dnf will handle this as appropriate. https://src.fedoraproject.org/rpms/bash/pull-request/18
(In reply to Nicolas Chauvet (kwizart) from comment #10) > I expect dnf will handle this as appropriate. It will not -- see bug #1566070.
Yep although --allowerasing is a sane workaround that might be used while upgrading with system-upgrade. (to be confirmed). That been said I expect the urgent tasks is to purge the bash{,-devel}.i686 from the f31 tree or I expect it will have side effect for the whole f31 lifetime. Handling upgrade path from f29 to f31 can be done on a second step. post GA.
I don't really see the justification for release blocker here. The bug isn't new to F31 (so we don't have to worry about people encountering it on upgrade where they didn't before). multilib_policy=all is not a thing in the release criteria at all, and I'm not sure it's possible to enable it at install time, at least not without doing something pretty obscure. So far I'm not seeing why this can't just be fixed as a post-release update?
I think this could be solved by putting the packages on the multilib blacklist. For this to happen we would need a ticket like this: https://pagure.io/releng/issue/6855
(In reply to Adam Williamson from comment #13) ... > I'm not seeing why this can't just be fixed as a post-release update? Because it will be impossible to fix as the bash.i686 will remain in the f31 GA repo for the whole lifetime. Package must be installable is probably a release criterion. This bug is new in the sense that f31 will be the first release to canonize bash.i686 in the GA repo. With that said having a multilib blacklist is probably an appropriate workaround (but I guess it will have to be set as a freeze exception or blocker).
Ticket for the multilibs blacklist https://pagure.io/releng/issue/8906 Can we have a build fixing this issue for rawhide and an updates propose for f31 (we can later talk about either this apply to GA/updates) ? Thx in advances.
"Package must be installable is probably a release criterion." Only for packages on the Server DVD. I'm pretty sure we usually ship multiple non-installable packages in the frozen repos (it's hard to be sure these days as the automated depclosure checks for nightly composes don't work any more). I can see an FE to avoid having the non-installable package in the frozen repo, I guess, but I'm not seeing blocker.
(In reply to Nicolas Chauvet (kwizart) from comment #16) > Ticket for the multilibs blacklist > https://pagure.io/releng/issue/8906 Thanks! > Can we have a build fixing this issue for rawhide and an updates propose for > f31 (we can later talk about either this apply to GA/updates) ? Build of what? The proposed rename of bash-devel is not an option in my view.
(In reply to Kamil Dudka from comment #18) .. > Build of what? > > The proposed rename of bash-devel is not an option in my view. Well at that point you need to elaborate because it's the very "root cause" of the issue. The devel is a very reserved keyword for a sub-package because it expects development for a "library". There is no such thing in the bash component only headers (and pc file to detect various variable). This headers package is not at all relevant for multilibs. (so there is no point to fix the multilibs installations issues, that would be the wrong approach). /me is out for tonight, please make the appropriate actions (or elaborate to better understand what you are missing)
(In reply to Nicolas Chauvet (kwizart) from comment #19) > The devel is a very reserved keyword for a sub-package because it expects > development for a "library". Nope. This is not what the related guideline says: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages I think that the bash-devel package is named correctly as it is. > /me is out for tonight, please make the appropriate actions (or elaborate to > better understand what you are missing) I do not want to over-complicate things by suddenly renaming a package that has existed for 2 years already.
(In reply to Kamil Dudka from comment #20) ... > I think that the bash-devel package is named correctly as it is. Okay so at least: Can you agree that the current bash-devel is currently broken because non-installable ? (same for bash) What is the appropriate way to have this issue fixed in your mind?
(In reply to Nicolas Chauvet (kwizart) from comment #21) > Can you agree that the current bash-devel is currently broken because > non-installable ? (same for bash) I believe these packages are installable in the commonly used environments. > What is the appropriate way to have this issue fixed in your mind? The releng ticket mentioned in comment #16. Note that I am not the (primary) maintainer of bash, so it is ultimately not my decision (and I see no urgency to make the decision right now).
(In reply to Kamil Dudka from comment #22) ... > > What is the appropriate way to have this issue fixed in your mind? > > The releng ticket mentioned in comment #16. > > Note that I am not the (primary) maintainer of bash, so it is ultimately not > my decision (and I see no urgency to make the decision right now). Ok, so we both agree on that's a way this bug can to be fixed. The urgency here is because the f31 GA repo is going to be closed, not fixing this issue before will make the bug harder to be cleared for f31.
(In reply to Nicolas Chauvet (kwizart) from comment #23) > The urgency here is because the f31 GA repo is going to be closed, not > fixing this issue before will make the bug harder to be cleared for f31. On the other hand, doing ad-hoc changes closely before f31 GA can potentially cause some breakage with higher impact somewhere else.
As per comment 17, I am -1 Blocker, +1 FE
Discussed at 2019-10-17 Fedora 31 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-10-17/f31-final-go_no_go-meeting.2019-10-17-17.00.html . Rejected as a blocker but accepted as a freeze exception issue: this does not violate any criteria we can see, but it would be good to avoid an uninstallable package being in the release repos. This is accepted as an FE on the understanding the fix will be to add bash-devel to the multilib blacklist in pungi-fedora f31 branch.
The blacklist PR was merged to F31 pungi-fedora, so we can call this ON_QA. The next compose should have bash-devel.i686 omitted from the x86_64 repo.
I confirmed that the RC compose has no bash-devel.i686 in its x86_64 repo, so closing this.
I confirm the issue is fixed. However I would like to remind for clarity that the way bash "headers" are consumed is quite un-usual. Assuming theses headers can be redistributed in a devel sub-package which is a "reserved keyword" that will imply several properties, specially for multilibs, is not appropriate. I might escalate this to the packaging committee eventually at some point, because it's not clean that an exeption list has to be maintained that modify the behavior at the repository level whereas this could be fixed at the package level.
In others words, to me the appropriate fix is that: https://src.fedoraproject.org/rpms/bash/pull-request/18#request_diff