Description of problem: Spot added the following change to the kernel on July 12: diff --git a/kernel.spec b/kernel.spec index f52266c..1b50f1d 100644 --- a/kernel.spec +++ b/kernel.spec @@ -2175,6 +2175,8 @@ fi %if %{1}\ %{expand:%%files -f kernel-%{?2:%{2}-}core.list %{?2:%{2}-}core}\ %defattr(-,root,root)\ +%{!?_licensedir:%global license %%doc}\ +%license linux-%{KVERREL}/COPYING\ /%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2:+%{2}}\ /%{image_install_path}/.vmlinuz-%{KVERREL}%{?2:+%{2}}.hmac \ %ifarch %{arm} aarch64\ @@ -2238,6 +2240,9 @@ fi # ||----w | # || || %changelog +* Sat Jul 12 2014 Tom Callaway <spot> +- Fix license handling (I hope) + * Fri Jul 11 2014 Josh Boyer <jwboyer> - 3.16.0-0.rc4.git3.1 - Linux v3.16-rc4-120-g85d90faed31e That has been working fine (as far as I can tell) in all of the 3.16 pre-release kernels we've built. The -rc4 through -rc7.git4.1 builds all install as expected. Today I built the final 3.16 kernel, and I get the following from RPM when I try to install it: [jwboyer@lando kernel]$ sudo rpm -ivh ./x86_64/kernel-3.16.0-2.fc21.x86_64.rpm ./x86_64/kernel-core-3.16.0-2.fc21.x86_64.rpm ./x86_64/kernel-modules-3.16.0-2.fc21.x86_64.rpm Preparing... ################################# [100%] file /usr/share/licenses/kernel-core/COPYING from install of kernel-core-3.16.0-2.fc21.x86_64 conflicts with file from package kernel-core-3.16.0-0.rc7.git0.1.fc21.x86_64 file /usr/share/licenses/kernel-core/COPYING from install of kernel-core-3.16.0-2.fc21.x86_64 conflicts with file from package kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64 [jwboyer@lando kernel]$ I uninstalled and reinstalled kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64 and it installs fine. The RPM db correctly has the /usr/shar/licenses/kernel-core/COPYING file owned: [jwboyer@lando kernel]$ rpm -qf /usr/share/licenses/kernel-core/COPYING kernel-core-3.16.0-0.rc7.git0.1.fc21.x86_64 kernel-core-3.16.0-0.rc7.git4.1.fc21.x86_64 [jwboyer@lando kernel]$ And the locally built package has the file marked as a license file correctly: [jwboyer@lando kernel]$ rpm -qpL ./x86_64/kernel-core-3.16.0-2.fc21.x86_64.rpm /usr/share/licenses/kernel-core/COPYING [jwboyer@lando kernel]$ Using rpm2cpio to extract the files from the locally built package, the sha256sums of the installed COPYING file and file contained in the RPM match: [jwboyer@lando foo]$ sha256sum `pwd`/usr/share/licenses/kernel-core/COPYING af8067302947c01fd9eee72befa54c7e3ef8a48fecde7fd71277f2290b2bf0f7 /home/jwboyer/kernel/foo/usr/share/licenses/kernel-core/COPYING [jwboyer@lando foo]$ sha256sum /usr/share/licenses/kernel-core/COPYING af8067302947c01fd9eee72befa54c7e3ef8a48fecde7fd71277f2290b2bf0f7 /usr/share/licenses/kernel-core/COPYING [jwboyer@lando foo]$ So at the moment, I have no idea why RPM is saying this is a file conflict. Help? Version-Release number of selected component (if applicable): [jwboyer@lando kernel]$ rpm -q redhat-rpm-config rpm rpm-build redhat-rpm-config-24-2.fc21.noarch rpm-4.11.90-0.git12844.5.fc21.x86_64 rpm-build-4.11.90-0.git12844.5.fc21.x86_64 [jwboyer@lando kernel]$ Additional info: I kicked off the builds in koji this morning to see if that makes a difference vs. a locally built kernel, but I would suspect it won't. The RPM version is identical on my F21 machine as to what is being used in the F21 chroots.
(In reply to Josh Boyer from comment #0) > Additional info: > > I kicked off the builds in koji this morning to see if that makes a > difference vs. a locally built kernel, but I would suspect it won't. The > RPM version is identical on my F21 machine as to what is being used in the > F21 chroots. Oddly enough, the koji build installs fine. I have no idea why this is.
Files can conflict with other things than content, notably file permission bits and ownership can conflict as well, and so can directory symlinks but thats far less common.
As explained in email elsewhere, the problem is different file digest algorithms. Anything from koji will have SHA256 digests but your local builds use MD5 because a) you dont have redhat-rpm-config installed b) /usr/lib/rpm/redhat/macros has been edited c) %_binary_filedigest_algorithm configuration is overridden elsewhere
(In reply to Panu Matilainen from comment #3) > As explained in email elsewhere, the problem is different file digest > algorithms. Anything from koji will have SHA256 digests but your local > builds use MD5 because And is there any workarounds? I would use md5 hashing for backward compatibility with epel5. Could rpm be small smarter and do fallback to other hashes checking instead threat file as conflicting?
It cannot fall back to what is not there. Rpm needs the hash long before it has the actual file so its not possible to calculate other hashes as needed. Note that this only matters when you're trying to share files between packages built with different hash algorithms, that is not a very common situation in practise.