|
|
Subscribe / Log in / New account

Improving .deb

Improving .deb

Posted May 31, 2019 8:30 UTC (Fri) by nim-nim (subscriber, #34454)
In reply to: Improving .deb by wahern
Parent article: Improving .deb

The article ponders multi gig deb limitations and you point to a page that complains a few bytes are wasted in rpm metadata. Really?

You have all the tools to manipulate rpm files under Linux, you can even open them in generic non-Linux archiving tools like 7zip and it will *just* *work* (yes you will lose rpm-specific metadata. Just like you will lose iso-specific metadata when treating isos like a giant archive. If you absolutely refuse to use native rpm tools just uncompress the source rpm, the whole package is described in a human-readable spec file, you don't absolutely need to read the binary transformation of this same info).

The rpm installation/update process has a mind-numbing amount of entry points, with very specific (and weird) ordering, but the average packager does not have to think about them. When you *do* need to think about them, because the software being packaged has special needs, you’re happy to have them available (or, like pretty much everyone, you decide it’s all too complex, and try to do your own better simpler thing, and months later, when you've exhausted all the weird corner cases required by your software, and actually understand the problem space, you switch to native rpm-provided facilities, because now you actually understand why they need to behave the way they do. Of course some people are too lazy to actually fix all corner cases, or too proud to admit they were wrong, so they will push garbage that does not make use of the tech capabilities, and complain rpm is awful). It's the same difference between an init tech with barebones facilities, that requires you to write giant custom scripts to work (SysV init), and something with built-in capabilities, that requires knowing the manual to call the built-in capabilities correctly (systemd).

And the rest is just the packaging policies and rules of each distro, which are not the same, so anyone looking at the packages done by other distros will be lost and unhappy, and only people that mistake their habits with natural laws of nature will seriously complain about it (yes, Debian packaging is weird and crufty too when looked at by outsiders). And two rpm distros won't do things the same way because they don't have the same opinions, and so would two deb distros.

The rpm format is actually nice enough many distributions adopted it and do their own different thing with it. And yes it also provides automation facilities in form of macros, so you don't have to do it all by hand, and distros with different opinions and objectives will automate things differently, what's the problem with that? It's like complaining not two Firefox users install the same extensions, and it's too hard to understand why two Firefoxes do not behave the exact same way.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds