aboutsummaryrefslogtreecommitdiffstats
path: root/config/tgz.am
Commit message (Collapse)AuthorAgeFilesLines
* Don't build packages that haven't been selected.Etienne Dechamps2012-07-261-0/+4
| | | | | | | | | | | | | Currently, when configure --with-config is used, selective compilation is only effective for the simple "make" case. Package builders (e.g. make rpm) still build everything (utils and modules). This patch fixes that. This patch also drops the duplicate rpm-modules build target. Signed-off-by: Brian Behlendorf <[email protected]> Signed-off-by: Prakash Surya <[email protected]> Issue zfsonlinux/zfs#851
* Avoid 'rpm -q' bug for 'make pkg'Brian Behlendorf2011-06-161-2/+2
| | | | | | | | | | | | | | | RPM version 4.9.0 has been observed to generate extra debug messages in certain cases. These debug messages prevent us from cleanly acquiring the architecture. This is clearly an upstream RPM bug which will get fixed. But until then a safe solution is to pipe the result through 'tail -1' to just grab the architecture bit we care about. Example 'rpm -qp spl-0.6.0-rc4.src.rpm --qf %{arch}' output: Freeing read locks for locker 0x166: 28031/47480843735008 Freeing read locks for locker 0x168: 28031/47480843735008 x86_64
* Add Debian and Slackware style packaging via alienBrian Behlendorf2010-07-271-0/+42
The long term fix for Debian and Slackware style packaging is to add native support for building these packages. Unfortunately, that is a large chunk of work I don't have time for right now. That said it would be nice to have at least basic packages for these distributions. As a quick short/medium term solution I've settled on using alien to convert the RPM packages to DEB or TGZ style packages. The build system has been updated with the following build targets which will first build RPM packages and then convert them as needed to the target package type: make rpm: Create .rpm packages make deb: Create .deb packages make tgz: Create .tgz packages make pkg: Create the right package type for your distribution The solution comes with lot of caveats and your mileage may vary. But basically the big limitations are that the resulting packages: 1) Will not have the correct dependency information. 2) Will not not include the kernel version in the release. 3) Will not handle all differences between distributions. But the resulting packages should be easy to install and remove from your system and take care of running 'depmod -a' and such. As I said at the top this is not the right long term solution. If any of the upstream distribution maintainers want to jump in and help do this right for their distribution I'd love the help.