Hi
where is this dependency from?
after confirm you can happily "yum remove linux-firmware" without any problems and the next kernel update pulls it again which is not how a normal dependency works because it would not allow to uninstall the dependency without remove the pulling package
hence why i have on our virtualized infrastructure for years a empty meta-package with provides/obsoletes but given now that we have "kernel-core" and "kernel-drivers" this dependecy should be only pulled only by "kernel-drivers" _____________________________________________________
---> Package kernel-core.x86_64 0:3.15.0-0.rc3.git3.1.fc21 will be installed --> Processing Dependency: linux-firmware >= 20130724-29.git31f6b30 for package: kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 ---> Package libcap-ng.x86_64 0:0.7.4-1.fc21 will be updated ---> Package libcap-ng.x86_64 0:0.7.4-2.fc21 will be an update ---> Package lyx-fonts.noarch 0:2.1.0-0.fc21 will be updated ---> Package lyx-fonts.noarch 0:2.1.0-2.fc21 will be an update ---> Package vim-minimal.x86_64 2:7.4.258-1.fc21 will be updated ---> Package vim-minimal.x86_64 2:7.4.258-2.fc21 will be an update --> Running transaction check ---> Package linux-firmware.noarch 0:20140317-37.gitdec41bce.fc21 will be installed --> Finished Dependency Resolution --> Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies _____________________________________________________
Name : linux-firmware Arch : noarch Version : 20140317 Release : 37.gitdec41bce.fc21 Size : 50 M Repo : installed _____________________________________________________
[root@rawhide ~]# rpm -qa | grep kernel kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64 _____________________________________________________
Is this ok [y/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Erasing : linux-firmware-20140317-37.gitdec41bce.fc21.noarch 1/1 Verifying : linux-firmware-20140317-37.gitdec41bce.fc21.noarch 1/1
Removed: linux-firmware.noarch 0:20140317-37.gitdec41bce.fc21 _____________________________________________________
[root@rawhide ~]# rpm -qa | grep kernel kernel-core-3.15.0-0.rc3.git3.1.fc21.x86_64 kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64
On Thu, May 1, 2014 at 1:24 PM, Reindl Harald h.reindl@thelounge.net wrote:
Hi
where is this dependency from?
From the explicit Requires(pre) in the kernel-core RPM.
after confirm you can happily "yum remove linux-firmware" without any problems and the next kernel update pulls it again which is not how a normal dependency works because it would not allow to uninstall the dependency without remove the pulling package
That's why it's Requires(pre).
hence why i have on our virtualized infrastructure for years a empty meta-package with provides/obsoletes but given now that we have "kernel-core" and "kernel-drivers" this dependecy should be only pulled only by "kernel-drivers"
No. The kernel-core package contains drivers that require firmware in linux-firmware. I'm not dropping that dependency. Your existing solution should continue to work.
josh
Am 01.05.2014 19:28, schrieb Josh Boyer:
On Thu, May 1, 2014 at 1:24 PM, Reindl Harald h.reindl@thelounge.net wrote:
where is this dependency from?
From the explicit Requires(pre) in the kernel-core RPM.
after confirm you can happily "yum remove linux-firmware" without any problems and the next kernel update pulls it again which is not how a normal dependency works because it would not allow to uninstall the dependency without remove the pulling package
That's why it's Requires(pre)
ah - i missed that bit all the years "playing" with rpm-SPEC's
hence why i have on our virtualized infrastructure for years a empty meta-package with provides/obsoletes but given now that we have "kernel-core" and "kernel-drivers" this dependecy should be only pulled only by "kernel-drivers"
No. The kernel-core package contains drivers that require firmware in linux-firmware. I'm not dropping that dependency. Your existing solution should continue to work
thanks for clarification and the hyperfast feedback anyways - thank you for your great work on Fedora kernels!
i am fine with my workaround while my repo-strcuture needs some optimization to have that package in a own private repo only consumed by virtual machines, currently it's excluded here and there to not hit phyiscal machines
by not knowing that much of kernel package internas i thought that could have been a piece better targeted for the new sub-package
kernel@lists.fedoraproject.org