Bug 1126380 - File conflict on kernel %license file
Summary: File conflict on kernel %license file
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-04 09:53 UTC by Josh Boyer
Modified: 2014-11-17 08:24 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-11 10:22:05 UTC


Attachments (Terms of Use)

Description Josh Boyer 2014-08-04 09:53:39 UTC
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@fedoraproject.org>
+- Fix license handling (I hope)
+
 * Fri Jul 11 2014 Josh Boyer <jwboyer@fedoraproject.org> - 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.

Comment 1 Josh Boyer 2014-08-04 12:37:29 UTC
(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.

Comment 2 Panu Matilainen 2014-08-06 07:23:06 UTC
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.

Comment 3 Panu Matilainen 2014-08-11 10:22:05 UTC
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

Comment 4 Pavel Alexeev 2014-11-17 08:16:25 UTC
(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?

Comment 5 Panu Matilainen 2014-11-17 08:24:48 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.