python-ctypes package is a virtual provides in python's SPEC file, since ctypes is now in stdlib. I intend to remove this virtual provides from python, so instead of depending on python-ctypes, libsmbios should depend on python2.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
just tested build with following change, still works (not tested on dell box) ############## -Requires: python %{ctypes_BR} +Requires: python
https://src.fedoraproject.org/rpms/libsmbios/pull-request/2
*** Bug 1516516 has been marked as a duplicate of this bug. ***
So, this bug *technically* should block the Fedora 27 Server release. This is because python-smbios is on the Server DVD, and it cannot be installed due to this dependency issue. This is a violation of https://fedoraproject.org/wiki/Fedora_27_Final_Release_Criteria#no-broken-packages - "There must be no errors in any package on the release-blocking images which cause the package to fail to install." I'm gonna argue we can reasonably except this case, though, due to the details. At least as I understand them. I believe the only things that depend on python-smbios, directly or indirectly, are: firmware-addon-dell smbios-utils-python smbios-utils yum-dellsysid I believe it's pulled into the DVD via firmware-addon-dell, which is an "optional" package in two comps groups, hardware-support and hardware-support-server . Since the newUI rewrite of anaconda (yes, that long ago), "optional" packages in comps groups are sort of an oddity. They get pulled into DVD composes, but it's rather difficult to actually get them included in an installation transaction. Unless anaconda selects them for install somehow (and it doesn't look like anaconda can select any of the above packages for installation), the only way you can get it to happen is by using a kickstart. With oldUI, the package selection step included an interface which showed you the 'optional' packages and allowed you to select them for installation - this is where the 'optional' concept *came* from initially, it meant "package in this group that isn't selected for install by default but which the user can choose to install", while 'default' meant "package that is selected by default but which the user can unselect" and mandatory meant "package that is selected by default and which the user cannot unselect". With newUI removing the UI for package-by-package selection, the anaconda became somewhat de-synchronized from the intent of these comps concepts. (This has bugged me for a while, but I haven't proposed some kind of wholesale change to comps because of the complicating factor that dnf also cares about these 'priority' settings in comps on some level). The reason we have this criterion is to avoid cases where users can easily trigger an uninstallable scenario from the installer UI; we think that's very bad - the thing we're trying to avoid is the bug report "I just picked a couple of package groups for install and the installer told me it can't install because of dependency errors!" So since it's not actually possible for this bug to cause that consequence, I'm gonna argue it doesn't need to block. You *could* in theory manage to trigger the dependency error by installing from a kickstart that included one of the packages listed above in its %packages section, but I suspect that's fairly uncommon and not worth blocking on.
(In reply to Adam Williamson from comment #5) > So since it's not actually possible for this bug to cause that consequence, > I'm gonna argue it doesn't need to block. You *could* in theory manage to > trigger the dependency error by installing from a kickstart that included > one of the packages listed above in its %packages section, but I suspect > that's fairly uncommon and not worth blocking on. I think that's a reasonable finding and I'm also -1 to block here. Thanks for doing the digging, Adam.
BTW, I did test my above understanding: I booted the Server DVD and selected the "Fedora Server" environment group and the "Hardware Support for Server Systems" (which is server-hardware-support) package group for installation. There were no warnings or errors and the install completed successfully. And there indeed is nowhere in the UI I could cause the optional firmware-addon-dell package to be selected for installation, AFAICS. I also checked anaconda's code and verified that it doesn't look like it can cause any of the mentioned packages to be installed (e.g. when Dell server hardware is detected, they get selected for install, or anything like that).
I am OK to make an exception for this case. Even formally the criterion is broken the bug should affect only a minority of users. -1 to block
I am ok with this. -1 to block
So with 4 -1 votes, let's reject this as a blocker per the rationale in comment #5.
libsmbios-2.3.3-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fde6ebddb6
libsmbios-2.3.3-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fde6ebddb6
libsmbios-2.3.3-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1522905 has been marked as a duplicate of this bug. ***