5 ms·

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

by pornel 8y ago

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

nailer 8y ago
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.
- icebraining 8y ago
  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?
  - nailer 8y ago
    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.
    - icebraining 8y ago
      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.
      - nailer 8y ago
        Yeah. That's his problem - it's not "to make matters worse" (as OP writes) it's the entire issue.

by pornel 8y ago

nailer 8y ago

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.

icebraining 8y ago
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?
- nailer 8y ago
  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.
  - icebraining 8y ago
    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.
    - nailer 8y ago
      Yeah. That's his problem - it's not "to make matters worse" (as OP writes) it's the entire issue.