RFC: What you don't like about RPM packaging?

Project Discussion
1

Hello fellow packagers,

I would like to ask you to dump things you don’t like about packaging. Please be constructive and share samples :wink:

3 Likes
2

Honestly the only thing that’s really bugged me so far is the fact that all files need to be listed out in a the .rpmspec.

1 Like
3

Why that bothers you? I mean you want to have control of what goes into the package, no? Also you don’t need to list all files, listing top-level directories is enough.

3 Likes
4

What I like about it is that it’s a very simple one file to edit and you’re done. This is great when I compare to deb for example. What I like also is the mature set of RPM macros we have in Fedora.

Sometimes I’d like listing the BR ard R so be automated. Finding all the BR can be a bit of trial and error when upstream doesn’t list them.

Also the changelog. I find it mostly useless row that we have git. And with “fedpkg ci -cp”, it’s mostly mirored. When I need to find out what change a SPEC had gone through, I look at the commit log first on Paqure, not the %changelog.

2 Likes
5
  1. Even spec files which start out as boilerplate drift into special cases over time
  2. Very manual; automation is hard
  3. changelogs are a pain
3 Likes
6

@mattdm, Actually for some set of the packages, automation is doable (most of Rust packages can be generated automatically, and manual bits can be stored in config). What is manual is just license check.

The real problem here is that there is no way to do that from infrastructure right now, so I have to regenerate them manually.

1 Like
7

Echoing previous thoughts on the changelog, it does seem limited in its usefulness, and in the case of a package I co-maintain (ndctl), we have the fedora spec right in the upstream package. We don’t reflect the %changelog changes back to the upstream file, but any changes/updates to the spec go into upstream first.

Drafting a new release now involves consolidating the upstream spec changes with the existing %changelog section (git definitely makes this easier). If this section were to disappear, a new release would be a simple `cp upstream.spec package.spec’ operation.

1 Like
8

FYI, you are supposed to merge any changes in Fedora package back to upstream and not blindly replace spec file.

1 Like
9

I’m not sure I follow… Are you saying the changelog updates in the fedora package are required to make it back to the upstream?

1 Like
10

No, for instance you get entry in changelog about mass rebuild. No one cares if you have it in upstream or not, but you should not delete it in Fedora package.

1 Like
11

Correct - we don’t delete it. That was my point when saying “consolidate upstream spec updates with existing changelog section”.
However in a brave new world without a changelog section, we would be able to simply copy/replace from upstream without a lot of manual work.

1 Like
12

What I like about it is that it’s a very simple one file to edit and you’re done. This is great when I compare to deb for example. What I like also is the mature set of RPM macros we have in Fedora.

Absolutely agree.

Sometimes I’d like listing the BR ard R so be automated. Finding all the BR can be a bit of trial and error when upstream doesn’t list them.

+1

Not sure this is really about RPM packaging but more about Fedora’s packaging process: What always bugged me a bit is the handling of the tree of package specs. On Arch Linux, or the BSDs, even Homebrew, what you do is you do a cvs up or git pull and you have all the package specifications. If you want to change something, especially not your own package, you’d submit a patchset or PR and that might be reviewed and merged. Proven packager or not. In Fedora it seems more complicated, more political. It requires special tools like fedpkg to get stuff done, sometimes even human involvement (requesting a new package repo).

2 Likes
13

For existing packages, you can do the same – submit pull request. However, if you want new package, then you need to pass review request which is complicated (because process is too complicated).

It would be cool to improve package review procedure.

2 Likes
14

What I typically do for the changelog is a few words describing the reason for the update, such as bugfix, upstream release and then follow it with a reference to a bugzilla ticket - so the whole thing would look like:
Upstream release - rhbz#123456

That allows for me to give a detailed explanation within the bugzilla ticket as to what occurred and why - if anyone is interested - while keeping the comments within the spec file to the bare minimum.

1 Like
15

Yes, but then you have to copy it over to the git commit message. So the point @eclipseo and @mattdm have is about duplicating same information twice.

1 Like
16

Well, all I’m copying over to the git commit is rhbz#123456 - a pointer to the bugzilla record that has all the details and a discussion history of the change. The reason I like this approach is because bugzilla is the go to place to search for issues. This way, people get the full picture in narrative format (if desired) rather than parsing through source code.

2 Likes
17
  1. specifying github tarballs as source urls:
%global commit0 e2fef4d889eb6cbf703d68004c068bc82ebee5b2
%global	shortcommit0 %(c=%{commit0}; echo ${c:0:7})
Source0: https://github.com/XXXXXX/%{name}/archive/%{commit0}/%{name}-%{shortcommit0}.tar.gz

ugh

  1. changelogs are annoying at best
3 Likes
18

With Forge-hosted projects packaging automation - Fedora Project Wiki, it should become better. Stay tuned for Packaging Guidelines update.

1 Like
19

That is a wider concern but basically, what I don’t like about RPM packaging is that it is distribution specific and the work does not seem to add much value.
Well explained in this video from the “All Systems Go” conf: 2018 Desktop Linux Platform Issues - YouTube

1 Like
20

I don’t have experience with creating other types of packages, but getting started with rpm for me was very difficult. I was happy to be able to help, and happy that I pushed through the process and learned something. At the same time, the package I created was really quite simple. I was not left with a desire to work on anything more complicated.

Here is a list of docs I consulted when trying to package up a php extension;

I probably left out a few. It still took me a few tries to fix all of the reviewer’s notes ( whoever did the review was great! Very professional and courteous. ) When I did ask questions in other spaces (irc, etc.) - the feedback was helpful, timely, and on point.

Having gone through this, I have to say the consistency in documentation makes the needed research a bit intimidating. I dislike wasting people’s time and go to lengths to not ask questions I could find the answer to myself. When I see people say, there are hundreds of macros that are used in packaging, if I’m honest, it puts a chill on wanting to learn more about packaging.

4 Likes