I don't really know why this guy was freaking out.
I also like the fact that transient dependency and repo handling is separated from the package handler itself. We have rpm to handle a single package, and we have dnf (yum) to handle trees of packages.
That's clearly explained in the article. This is not about authoring from a specfile, so your comment is off. He wants to serialise a package into RPM without the traditional toolchain; it turns out to be much more difficult than the other serialisers he already has because of the rpm format's bad design decisions and accretions.
Plus, RH could have decided to make a proper v2 rather than build this lasagna of a format.
So was DEB. That's not a very good excuse.
Formats defined by a single implementation are sickly and much less viable (remember the lessons of http://libmng.com/ ?); I applaud the reverse engineering effort from the article.
Yes! There are lots of examples like this.
• Plenty of small tools write BMP or Targa instead of JPEG or PNG, because these formats are dead simple to reinvent.
• JPEG as we know it is JFIF, which has clearly won over alternative JPEG data containers, such as more complicated TIFF (mode 6). BTW JPEG, for what it does, is brilliantly simple.
• MNG never took off, but dumber APNG did.
Formats that are intended for interoperability need multiple implementations, and it does happen that authors say "no, fuck that" and choose a different format instead.
But, let's consider that I have never had an RPM-using system have its package database corrupted beyond repair (you can rebuild it with rpmdb --rebuilddb), and unlike dpkg/deb, rpm fully supports downgrading packages, which is something I have missed on Debian multiple times.
RPM is too complex, but it's also a good format from a reliability standpoint.
you've had that on Debian?
> rpm fully supports downgrading packages, which is something I have missed on Debian multiple times
Huh? Downgrades are fully supported by dpkg and apt*.
No, they aren't. You need to remove the newer version prior to installing the old one. RPM based systems allow you to downgrade to an entirely different distro release with one command.
> you've had that on Debian?
More than once, sadly.
> The <rpm/rpmtag.h> header has an enum with all acceptable values, but please consider the environment before trying to print it.
however, it would be incredible to have a single format
There are times i wonder if IT has some innate attraction to masochism...
There is no competition between package managers, there is only competition between distributions.
> the author was analysing trying to build a binary package directly.
To analyse, there's two approaches that have been well documented for around 20 years now:
- open the .src.rpm for a package
- Run the rpm binary over the .rpm, which can dump spec file contents too
- Make a spec file
Again, there's lots to dislike about RPM (my main issue is how the sections are macros and so are the autoconf macros), which confused a lot of new people) but this article in incredibly unresearched.
For this purpose it's fitting to do a deep analysis of files actually produced, rather than trust the documentation to be entirely complete and sufficient.
Such low-level dump is also needed to debug interoperability issues when files produced by the new implementation are rejected by existing tools.
I'm developing cargo-deb, which builds Debian packages without need for spec files. It doesn't use Perl, and can even build Debian packages from macOS. I had to learn and reproduce the structure of the deb files, which was relatively easy. I would need to go through exactly the same horror as in the article if I wanted to add RPM support the same NIH way (so RPM tooling may be good and easy, but RPM as a format is a failure.)
But even if I wanted to recreate RPM which the author does (although he doesn't state this) I'd start with the source code.
Yes, he does, right in the first paragraphs.
I'd start with the source code.
He started with the formal specification of the RPM format, which includes relevant pieces of the source; how is that not a good place to start?
> I ship configuration as system packages. Every distribution has their own tooling and process for building these packages, but I eventually grew tired of the ceremony involved in it, and wrote my own system package compiler.
Which to most engineers would mean making a tool that builds.rpm files, not reimplements the rpm build tools.
OP made it clear what they were focusing on. If a passerby mistakes it for a complaint about using RPM as a sysadmin, it's their own problem.