Hacker News Reader

Comment by nailer | Hacker News Reader

That's even worse. Why would you analyse a binary RPM to inspect it, when present that as a normal way to analyse or build RPMs?

> 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

To build:

- 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.

View on HN

Keep in mind that the author tried to build an independent implementation, so your complaint is like "Why are Gecko developers wasting time on reverse-engineering websites, instead of installing Chrome?"

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.)

If I was making something to build RPM packages automatically (like the author states), I'd still leverage the existing tools.

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.

although he doesn't state this

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?

No. He states:

> 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.

Read a bit further: I stubbornly refused to add dependencies and use existing tooling (i.e., the rpm-build(1) command). I wanted to serialize the format directly from my own code, like I did for Pacman and Debian packages.

Yeah. That's his problem - it's not "to make matters worse" (as OP writes) it's the entire issue.

Who cares why you do it? Maybe you're just curious. How does that invalidate the analysis?

It makes it seem like RPM is an incredibly difficult packaging system, when in reality the author has deliberately chosen an obscure and unusual way of working with it.

This is nothing to do with the packaging system or the ecosystem, the author decided to dive into the file format specifically. They even posted comments from the rpm source that echo the confusion and disbelief reflected in the article. Is the tone the author took the problem you have with it? Otherwise I don’t get why you are so against someone trying to learn how a file format works and documenting the experience.

I've built tools that automatically create RPM files in less time than the author tool to write this article. I take umbrage in the bizarre implication that building a tool to make RPMs needs you to dive into the format with a hex editor, when it does not.

ASN.1 and XML are easy to work with using the right existing tools, but that doesn't mean someone can't post their thoughts about them being frustrating formats.

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.

OP said they were trying to make a tool to automatically generate RPM packages. They didn't do this efficiently or reasonably at all.

In fairness, the author was trying to write his own RPM encoder, so not using existing tools was... less of a bad idea than usual. That said, I agree that this was under-researched.

Reply on news.ycombinator.com