Bug 1151123

Summary:	dkms-2.2.0.3-28.git.7c3e7c5.fc20.noarch broke builds of dkms packages that depend on other dkms packages
Product:	[Fedora] Fedora	Reporter:	Richard Yao <ryao>
Component:	dkms	Assignee:	Simone Caronni <negativo17>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	behlendorf1, charles_rose, cks-rhbugzilla, dajhorn, mario_limonciello, negativo17, tcallawa
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: "$dkms_tree/$module/$module_version/build" is unconditionally removed due to upstream commit 2ea43f6108558849125cc1d66902d6992ee3fe39. Consequence: DKMS packages that depend on autotools build products of other DKMS packages to build no longer build. Fix: Result:	Story Points:	---
Clone Of:		Environment:	Linux zfs-dev-20141009 3.10.0-123.el7.x86_64 #1 SMP Mon Jun 30 12:09:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Last Closed:	2014-12-05 08:32:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard Yao 2014-10-09 15:44:50 UTC

Description of problem:
As of last night, attempting to build any dkms package that depends on headers from another dkms package is broken on Fedora.

Version-Release number of selected component (if applicable):
2.2.0.3-28.git.7c3e7c5.fc20.noarch

How reproducible:

Every time

Steps to Reproduce:

Run the following on the latest Fedora:

1. sudo yum localinstall --nogpgcheck http://archive.zfsonlinux.org/fedora/zfs-release$(rpm -E %dist).noarch.rpm
2. sudo yum install kernel-devel zfs 

http://zfsonlinux.org/fedora.html

Actual results:

Autotools fails to find the headers that it needs to build ZFS because they are no longer available.

Expected results:

Autotools should have found them.

Additional info:

The dkms package was patched last year for issue #1023598 to prevent build failures when two dkms packages depend on one another. This iss needed by both ZFS (which depends on the SPL) and Lustre (which depends on ZFS). It worked because dkms left the build files around, such that key autotools products such as spl_config.h and zfs_config.h were accessible to the build systems that needed them. A recent upstream commit broke this:

http://linux.dell.com/cgi-bin/cgit.cgi/dkms.git/diff/dkms?id=2ea43f6108558849125cc1d66902d6992ee3fe39

The change suggests that leaving these files around was never upstream dkms' intention. Unfortunately, multiple projects (e.g. ZFS, Lustre) that have come to depend on having autotools generated headers from dependencies and this change makes the removal unconditional, such that there is no workaround.

Comment 1 Richard Yao 2014-10-09 17:54:31 UTC

To make a long story short, this is not a DKMS bug. The following pull requests fix it:

https://github.com/zfsonlinux/spl/pull/399
https://github.com/zfsonlinux/zfs/pull/2776

There was some misunderstanding as to what `dkms build` and `dkms install` meant. To put it another way, Gentoo Portage's package manager has the following main stages:

1. Fetch
2. Unpack
3. Prepare
4. Configure
5. Compile
6. Install
7. Clean
8. Merge

`dkms build` is 4 through 7 while `dkms install` is 8. Consequently, POST_BUILD should be used instead of POST_INSTALL on dkms.