So you post a German blog post about something you have never done. I now have gone full on salt.
Once again their is nothing wrong with RPM and this anti-RPM stuff needs to just die. Linus uses Fedora and if anyone would flip out if something was bad technology Linus would, but instead people who just heard a cool RPM Dependency Hell still continue this 10+ year old issue over and over again without knowing anything technical about why it was an issue (For a short period of time) and how it was fixed.
A) I know 3 ancient languages and have degrees in them undergrad and grad. Google Translate German is minimally okay at best. The most important aspects of languages are not words but sentence structure. That is lost on Google Translation BUT... what I can see is this guy is just raging about a missing dependency in the repos of a library last built in 2010 (5 years old). NOT AN RPM ISSUE.
2) Oh and who the RPM file format has since devised please ?! What's that supposed to be? If the alien invaders drive you crazy, so they can not exterminate mankind? Holy shit. By contrast, even the Debian stuff is obvious and self-explanatory! And self-documenting all. As a .deb works, one can find out with file and home remedies, you do not even need a hex editor."
C) This guy is clueless he says Gnome handles this better then RPM? What does a Desktop Environment have to do with RPM? Does he equate Gnome with Debian/Ubuntu and thinks Gnome is Deb?
"Does "deltarpm". Say, is that a joke here? Even Rotz Gnome checked before building if its dependencies are fulfilled!"
"First there are RPM directly two strands, RPM and RPM 4 5, and both claim to be the "official" RPM. Lolwut?"
E) Why would anyone need a hex editor for when looking at RPM its plain text?
If you can't find anything on the issue in several languages it isn't an issue. RPM is a stable good technology that people randomly out of what need to put down without knowingly what they are talking about.
Enough said about this stupid blog post:
"My goodness. And I know otherwise perfectly sane people who swear on CentOS!
Update: Maybe I should say, as I so imagine a package management tool. My request would be that always works. Python zerschossen? Perl is not installed? glibc update failed in the middle? The package manager needs to go and can still be saved. And it must be small enough to fit with metadata in 5 MB. Must also without OpenSSL and curl and wget can work, at least in an emergency. Of the systems that I've seen so far, I like best pacman (Arch Linux). But there is something else."
In all fairness, RPM really is a shitty package format [0]. It's a binary format with a lot of different versions, and any tool dealing with RPMs needs to be able to handle all those different versions. Compare that with nearly every other package format: a standard archive file with the package data and metadata stored within. This means that you need specialized tools to deal with RPM packages, whereas packages in other formats can be dealt with using standard archival and compression tools.
The situation could be a lot worse, for sure, but dealing with RPM packages is a pain in the ass compared to practically every other package format (programmatically speaking).
(I say this as the maintainer of a tool that converts RPMs to CRUX packages [1]).
2. Most of the complaints are about RPM's build chain and the bloat included in it. NSS/NSPR: RPM doesn't care about any standard ways of configuring them – nspr-config, pkg-config, LSB default folders, … ) BDB: Needs to be copied into RPM's source tree. RPM doesn't build its python modules (needed by yum etc.) by default. Yum has a hard dependency on sqlitecachec but doesn't declare it. (sqlitecachec is the piece of software from 2010, BTW.)
(No idea whether those are accurate.)
3. The gnome comparison is, again, related to the build system: RPM does not check all build- and runtime dependencies before building, you have to determine them by trial and error.
(No idea whether this is accurate either.)
4. RPM packages are binary, and to inspect them you either need specialized tools or, well, hex editors. (Also seems to be correct.) This is a marked difference from all competing formats, which are plain text. DEB packages are ar(1) archives with some special files, all ASCII text. Same for Pacman packages (which are tars).
5. I don't think his "package manager wishlist" is unreasonable. A statically compiled package manager that works without any external dependencies is desirable, as it e.g. allows cross-installation from other platforms, and makes the system harder to break with botched updates.
6. Another complaint is the dependency bloat: Why use a mixture of XML text databases (repodata) backed by an SQLite cache (yum) and BDB databases (rpm)? (No idea what's an accurate representation.)
Generally, Fefe has been lobbying for less complex, easier to maintain, easier to verify, more resource efficient software for over a decade. His projects – gatling, dietlibc, minit, fgetty … – show it.
Sure down vote BUT defend your opposition to the point of this blog post that I pointed out. It is 100% not RPM issues that this person is talking about.
Okay so by the down votes I guess people prefer to think RPM is bad and won't take anything from anyone pointing out how it works and that the article used was full of holes by someone that doesn't understand package management.
I SAID STUPID: Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
"this guy" and "this person" with the "stupid blog post" is Felix von Leitner, for reference. Understand that, and understand things like diet libc, libowfat, and minit, and you will understand some of the bases of M. von Leitner's opinions here.
> Ye sit is stupid to request a package manager that uses unsecured packages with disabled SSL and curl and wget to download packages and manage them so that any hacker could install any package it wants with a simple script.
That was not the demand. The demand was a package manager that works without requiring openssl as a dynamically linked dependency, so the package manager still works if those dependencies are broken or missing (due to e.g. a botched update) and can repair dynamic libraries for the rest of the system.
Once again their is nothing wrong with RPM and this anti-RPM stuff needs to just die. Linus uses Fedora and if anyone would flip out if something was bad technology Linus would, but instead people who just heard a cool RPM Dependency Hell still continue this 10+ year old issue over and over again without knowing anything technical about why it was an issue (For a short period of time) and how it was fixed.