1RPM Spec File Notes 2------------------- 3 4The RPM spec file provided here is for Bitcoin-Core 0.12.0 and builds on CentOS 57 with either the CentOS provided OpenSSL library or with LibreSSL as packaged 6at [LibreLAMP.com](https://librelamp.com/). It should hopefully not be too 7difficult to port the RPM spec file to most RPM based Linux distributions. 8 9When porting the spec file to build for a particular distribution, there are 10some important notes. 11 12## Sources 13 14It is considered good form for all sources to reference a URL where the source 15can be downloaded. 16 17Sources 0-9 should be reserved for source code tarballs. `Source0` should 18reference the release tarball available from https://bitcoin.org/bin/ and 19`Source1` should reference the BerkeleyDB source. 20 21Sources 10-99 are for source files that are maintained in the 22[Bitcoin git repository](https://github.com/bitcoin/bitcoin) but are not part of 23the release tarball. Most of these will reside in the `contrib` sub-directory. 24 25Sources 10-19 should be reserved for miscellaneous configuration files. 26Currently only `Source10` is used, for the example `bitcoin.conf` file. 27 28Sources 20-29 should be reserved for man pages. Currently only `Source20` 29through `Source23` are used. 30 31Sources 30-39 should be reserved for SELinux related files. Currently only 32`Source30` through `Source32` are used. Until those files are in a tagged 33release, the full URL specified in the RPM spec file will not work. You can get 34them from the git ropository where you retrieved this file. 35 36Sources 100+ are for files that are not source tarballs and are not maintained 37in the bitcoin git repository. At present only an SVG version of the Bitcoin 38icon is used. 39 40## Patches 41 42In general, patches should be avoided. When a packager feels a patch is 43necessary, the packager should bring the problem to the attention of the bitcoin 44developers so that an official fix to the issue can make it into the next 45release. 46 47### Patch0 bitcoin-0.12.0-libressl.patch 48 49This patch is only needed if building against LibreSSL. LibreSSL is not the 50standard TLS library on most Linux distributions. The patch will likely not be 51needed when 0.12.1 is released, a proper fix is already in the Bitcoin git 52master branch. 53 54## BuildRequires 55 56The packages specified in the `BuildRequires` are specified according to the 57package naming convention currently used in CentOS 7 and EPEL for CentOS 7. You 58may need to change some of the package names for other distributions. This is 59most likely to be the case with the Qt packages. 60 61## BerkeleyDB 62 63The `build-unix.md` file recommends building against BerkeleyDB 4.8.30. Even if 64that is the version your Linux distribution ships with, it probably is a good 65idea to build Bitcoin Core against a static version of that library compiled 66according to the instructions in the `build-unix.md` file so that any changes 67the distribution may make in the future will not result in a problem for users. 68 69The problem that can exist, clients built against different versions of 70BerkeleyDB may not be able read each other's `wallet.dat` file which can make it 71difficult for a user to recover from backup in the event of a system failure. 72 73## Graphical User Interface and Qt Version 74 75The RPM spec file will by default build the GUI client linked against the Qt5 76libraries. If you wish instead to link against the Qt4 libraries you need to 77pass the switch `-D '_use_qt4 1'` at build time to the `rpmbuild` or `mock` 78command used to build the packages. 79 80If you would prefer not to build the GUI at all, you can pass the switch 81`-D '_no_gui 1'` to the `rpmbuild` or `mock` build command. 82 83## Desktop and KDE Files 84 85The desktop and KDE meta files are created in the spec file itself with the 86`cat` command. This is done to allow easy distribution specific changes without 87needing to use any patches. A specific time stamp is given to the files so that 88it does not they do not appear to have been updated every time the package is 89built. If you do make changes to them, you probably should update time stamp 90assigned to them in the `touch` command that specifies the time stamp. 91 92## SVG, PNG, and XPM Icons 93 94The `bitcoin.svg` file is from the source listed as `Source100`. It is used as 95the source for the PNG and XPM files. The generated PNG and XPM files are given 96the same time stamp as the source SVG file as a means of indicating they are 97derived from it. 98 99## Systemd 100 101This spec file assumes the target distribution uses systemd. That really only 102matters for the `bitcoin-server` package. At this point, most RPM based 103distributions that still receive vendor updates do in fact use systemd. 104 105The files to control the service are created in the RPM spec file itself using 106the `cat` command. This is done to make it easy to modify for other 107distributions that may implement things differently without needing to patch 108source. A specific time stamp is given to the files so that they do not appear 109to have been updated every time the package is built. If you do make changes to 110them, you probably should update the time stamp assigned to them in the `touch` 111command that specifies the time stamp. 112 113## SELinux 114 115The `bitcoin-server` package should have SELinux support. How to properly do 116that *may* vary by distribution and version of distribution. 117 118The SELinux stuff in this RPM spec file *should* be correct for CentOS, RHEL, 119and Fedora but it would be a good idea to review it before building the package 120on other distributions. 121 122## Tests 123 124The `%check` section takes a very long time to run. If your build system has a 125time limit for package build, you may need to make an exception for this 126package. On CentOS 7 the `%check` section completes successfully with both 127OpenSSL and LibreSSL, a failure really does mean something is wrong. 128 129## LibreSSL Build Notes 130 131To build against LibreSSL you will need to pass the switch 132`-D '_use_libressl 1'` to the `rpmbuild` or `mock` command or the spec file will 133want the OpenSSL development files. 134 135### LibreSSL and Boost 136 137LibreSSL (and some newer builds of OpenSSL) do not have support for SSLv3. This 138can cause issues with the Boost package if the Boost package has not been 139patched accordingly. On those distributions, you will either need to build 140Bitcoin-Core against OpenSSL or use a patched version of Boost in the build 141system. 142 143As SSLv3 is no longer safe, distributions that have not patched Boost to work 144with TLS libraries that do not support SSLv3 should have bug reports filed 145against the Boost package. This bug report has already been filed for RHEL 7 but 146it may need to be filed for other distributions. 147 148A patch for Boost: https://github.com/boostorg/asio/pull/23/files 149 150## ZeroMQ 151 152At this time, this RPM spec file does not support the ZeroMQ build options. A 153suitable version of ZeroMQ is not available for the platform this spec file was 154developed on (CentOS 7). 155 156## Legacy Credit 157 158This RPM spec file is largely based upon the work of Michael Hampton at 159[Ringing Liberty](https://www.ringingliberty.com/bitcoin/). He has been 160packaging Bitcoin for Fedora at least since 2012. 161 162Most of the differences between his packaging and this package are stylistic in 163nature. The major differences: 164 1651. He builds from a github tagged release rather than a release tarball. This 166should not result in different source code. 167 1682. He does not build BerkeleyDB but instead uses the BerkeleyDB provided by the 169Linux distribution. For the distributions he packages for, they currently all 170use the same version of BerkeleyDB so that difference is *probably* just 171academic. 172 1733. As of his 10.11.2 package he did not allow for building against LibreSSL, 174specifying a build without the Qt GUI, or specifying which version of the Qt 175libraries to use. 176 1774. I renamed the `bitcoin` package that contains the Qt GUI to `bitcoin-core` as 178that appears to be how the general population refers to it, in contrast to 179`bitcoin-xt` or `bitcoin-classic`. I wanted to make sure the general population 180knows what they are getting when installing the GUI package. 181 182As far as minor differences, I generally prefer to assign the file permissions 183in the `%files` portion of an RPM spec file rather than specifying the 184permissions of a file during `%install` and other minor things like that that 185are largely just cosmetic. 186