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

rpmbuild requires that Source0’s basename be the same as the actual source archive present in the SOURCES directory.

It is very easy to rename the downloaded source archive, but this makes review of the package SPEC manual. A co-maintainer or a new maintainer would need to discover that I renamed the source archive just to satisfy rpmbuild's insistence on parity.

Here is an example changelog entry:

Changed the tar command in .spec file to address discrepancy between GitHub archive URI and downloaded source archive.

I should have indicated that I renamed the downloaded archive in the changelog, but otherwise it was a simple annoyance.

1 Like

Personally, as a sysadmin, my issue now is fighting between making a RPM or an Ansible Role for landing custom tools or changes to a system. With a lot of orgs and teams using Ansible for their automation it makes it hard to argue to having a RPM build system rather then an Ansible control node or Tower.

3 Likes

I found it confusing that there are not just packages and .spec files to build them, but also “package sources” and “source packages”, where “source package” is not just upstream sources, but it is RPM binary file (SRPM) that is built from .spec files that are stored in “package sources” repositories.

I would really a prefer simplified approach - where “packages” are built from “sourcepacks”, where “sourcepack” is a file tree with upstream source and metadata (.spec). So you have “package” built from “sourcepack” and there is nothing else. “Sourcepack” is a hashed directory tree. It can be an identical unpacked dir, git repo or archive as long as tree hash matches. I don’t get why binary SRPM format for “source package” is needed when they just could just be a simple .zip archive or whatever.

1 Like

I also don’t like that I can not mark packages as not manually installed. As a dependency of some other package. Like if I manually install some codecs for VLC, I want to mark them as dependent on VLC, so what when VLC is gone, these codecs are gone too.

https://bugzilla.redhat.com/show_bug.cgi?id=1615045

1 Like

@abitrolly, are you looking for dnf mark remove?

https://dnf.readthedocs.io/en/latest/command_ref.html#mark-command-label

dnf mark remove will just remove my codec (or dev lib) when i run autoremove, and I want it to stay as long as vlc stays, but no longer.

I think the suggestion of making your own RPM to encode those dependencies is really the best option. I think locally-added expressive dependency information could be a QA nightmare.

1 Like

I tried to make my own RPM like 3 times, and still can’t remember how to do it after python packaging workshop at the Nest conference. It is no YAML, no single tool that build everything from that single YAML. A lot of rituals with hashes and file placements (or was it in Debian?).

@abitrolly I follow this doc to get started, RPM Packaging Guide This helps me setup a VM for packaging and signing RPM’s. I good example I use is the SOS GitHub for setting up a RPM spec file for python application, the setup.py for the application, and add man pages if you application needs it. If you need any further help I can try and help.

1 Like

I’d recommend you try again. I’ve been helping folks with no packaging experience package up simple python modules, and they’ve been able to follow along well enough to now be sponsored package maintainers. The new Python guidelines really make packaging quite easy.

There is only one spec file for RPM packages, that includes all the information needed to build a package. I don’t know what the Debian system is.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/

There’s a template there too, that we use to get started.

1 Like

Some of this is just historical. The source RPMs really are just cpio archives (an old Unix format which had some generally-now-irrelevant advantages over tar) with a header. That’s probably not how we’d design it now, but eh.

However, in most modern workflows, you don’t really need to worry about the source package. That’s just a convenient bundle that we can put together with others to make sure we’re meeting our license obligations and etc. In most practical work, what you deal with is a dist-git tree — that is, like https://src.fedoraproject.org/ or CentOS rpms on gitlab.

But, you may be interested in going one step further to source-git — see Source Git :: Fedora Docs. This is, effectively, a work-in-progress implementation of some of the “more interesting improvements” that former Fedora Release Engineering team lead Jesse Keating laid out when announcing the creation of dist-git (from dist-cvs!) way back in 2010.

1 Like

Yeh, most of us don’t explicitly create src.rpm files anyway. We either use rpmbuild -ba or fedpkg mockbuild etc. which automatically create the src.rpm before starting the build.

The only place where I see the src.rpm being currently used is in package reviews where we provide the src.rpm (so the spec and sources and everything else) also.

1 Like

Yes, and I couldn’t get through it, and this article reminded that I am also using brew for the stuff I need in addition to snap and AppImage, and I like it so far.