quentin
/
quentin.dufour.io
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

First correc5tion

This commit is contained in:
Quentin 2018-05-20 14:00:19 +02:00
parent 2b80a8d4b6
commit beb4b18005
1 changed files with 37 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
_posts/2018-05-20-build-a-rpm-package-and-publish-it-on-copr.md
View File

@ -13,17 +13,17 @@ tags:
- rpm
---
*Disclaimer: I'm not an expert in linux packaging, some part could be considered as bad practises. Moreover, there are billions different ways of building packages. I am only proposing one in this article.*
*Disclaimer: I'm not a linux packaging expert, some parts could be considered as bad practises. Moreover, there are billions different ways of building packages. I am proposing only one in this article.*
### Setup
First of all, we will need some tools:
First of all, we will need some tools to build packages:
```bash
sudo dnf install git rpmdevtools rpm-build
```
RPM is a bit special, as it needs its own folder and can't build elsewhere. It's a bit annoying when you manage your packages in different repositories. We will see one way to get around this problem.
RPM is a bit special, as it needs its own folder hierarchy (stored by default in `~/rpmbuild`) and can't build without this hierarchy. It's a bit annoying when you manage your packages in different repositories. We will see one way to get around this problem.
First, create a git repository for your RPMs:
@ -41,7 +41,7 @@ rpmdev-newspec --macros chez-scheme.spec
You should have generated the following file:
```conf
```
Name: chez-scheme
Version:
Release: 1%{?dist}
@ -101,7 +101,6 @@ git commit -m "A second patch"
git format-patch v9.5
```
Another way is to download and extract the tarball, create a copy and use diff:
```bash
@ -111,8 +110,6 @@ cp -r v9.5 v9.5-src
diff -Naur v9.5-src v9.5 > some-modification.patch
```
We will use `patch -p0` for git patches as they don't include the main folder and `patch -p1` for diff patches as they include the main folder.
We will put these patches in our git repository, next to our `.spec` file:
```
@ -124,7 +121,22 @@ rpm
```
Now, if we want to build, we will have to type the following commands:
Applying patches and extracting tarball can lead to some problems.
First, patches can have different "roots". We will use `patch -p0` to apply git patches as they don't include the main folder and `patch -p1` for diff patches as they include the main folder.
If you use the `autosetup` macro in your `.spec` file, you will put (for diff patches):
```
%autosetup -p1
```
Second, once downloaded, your tarball doesn't necessarily extract in a folder of the name `<package>-<version>`. If it's not the case, you must precise it too:
```
%autosetup -p1 -n ChezScheme-%{version}
```
Now, if we want to build the RPM, we will have to type the following commands:
```bash
spectool -g -R ./chez-scheme.spec # Download sources
@ -132,14 +144,14 @@ cp *.patch ~/rpmbuild/SOURCES # Copy patches
rpmbuild -ba ./chez-scheme.spec # Build RPM
```
There are some tools like rpkg, fedpkg or tito that should do most of the steps for you.
Unfortunately, they are not very flexible. rpkg and fedpkg never download the source directly, but from a mirror, and fails with a 404. If I want to push my source to this mirror, it fails with an unauthorized error. These packages seem to be aimed at distribution maintainers. tito, for its part, doesn't handle correctly patches and sources. It consider that everything should be embedded in a single git repository.
There are some tools like rpkg, fedpkg or tito that can do most of the steps for you.
Unfortunately, they are not very flexible. rpkg and fedpkg never download the source directly, but from a mirror, and fails with a 404 as they don't find the file. If I want to push my source to this mirror, it fails with an unauthorized error. These packages seem to be aimed at distribution maintainers. tito, for its part, doesn't handle correctly patches and sources. It consider that everything should be embedded in a single git repository.
So, we will need an home made solution.
### make srpm
Fortunately, copr propose different solutions. One is to build your `.srpm` locally and send it to copr, but we can even avoid this step and only give a git repository to copr. We will build our own builder with a Makefile, which is supported by Copr!
Fortunately, copr propose different solutions. One is to build your `.srpm` locally and send it to copr, but we can even avoid this step and only give a git repository to copr: we will build our own builder with a Makefile.
Copr will call a Makefile located in `<git_root>/.copr` from the folder of our package (`<git_root>/chez-scheme`) and call:
@ -147,19 +159,6 @@ Copr will call a Makefile located in `<git_root>/.copr` from the folder of our p
make -f <git_root>/.copr/Makefile srpm outdir="<outdir>" spec="<spec_path>"
```
Your folder structure should now look like this:
```
rpm
├── chez-scheme
│   ├── chez-scheme.spec
│   ├── chez-scheme-symlink.patch
│  └── chez-scheme-xlocale.patch
└─── .copr
   └── Makefile
```
Copr proposes a simple Makefile in its documentation. I'm proposing a bit more complex one that use only `rpmbuild`:
```makefile
@ -180,6 +179,20 @@ rpm: prepare
The `rpm` target will not be used by Copr but it can be convenient to locally test your package build before sending it to Copr.
Your folder structure should now look like this:
```
rpm
├── chez-scheme
│   ├── chez-scheme.spec
│   ├── chez-scheme-symlink.patch
│  └── chez-scheme-xlocale.patch
└─── .copr
   └── Makefile
```
You really have to put the Makefile here, otherwise copr will not find it.
### Use Copr
Now you just need to commit + push your repository and use the [Copr web interface](http://copr.fedorainfracloud.org/) to create a new project, add a package and trigger a build !