Bug 1151123 - dkms-2.2.0.3-28.git.7c3e7c5.fc20.noarch broke builds of dkms packages that depend on other dkms packages
Summary: dkms-2.2.0.3-28.git.7c3e7c5.fc20.noarch broke builds of dkms packages that de...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dkms
Version: 20
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Simone Caronni
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-09 15:44 UTC by Richard Yao
Modified: 2014-12-05 08:32 UTC (History)
7 users (show)

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:
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
Embargoed:


Attachments (Terms of Use)

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.


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