Improving .deb
Improving .deb
Posted May 28, 2019 21:10 UTC (Tue) by jhoblitt (subscriber, #77733)Parent article: Improving .deb
Posted May 28, 2019 21:27 UTC (Tue)
by compenguy (guest, #25359)
[Link] (4 responses)
The database format of rpms is painful to deal with, and really rather impractical for some of the use cases described in the article, such as extracting the installer contents for manual installation on an unsupported system.
Also, most of the linux installation professionals I know hate rpm with a passion and would much rather work with deb packages, for a host of reasons not directly relating to the file format itself. The state management for package install/upgrade/uninstall is more robust and intuitive for deb being one of the really big ones. I will say, though, that on the deb side of things, I miss rpm's autoreq/autoprov system. Deb's tooling doesn't let you provide/require a SONAME, rather the tooling will look at known packages and use the name of the package that installs that lib as the dependency.
Most of the rest is kind of a grey area of just having different design patterns for solving different kinds of installation problems.
Posted May 30, 2019 15:50 UTC (Thu)
by imMute (guest, #96323)
[Link] (1 responses)
I wonder if this wouldn't be possible in debs with some creative use of Provides and Requires. A package containing a library that "provides" some SONAME could have a "Provides: SONAME-libfoo.so.2" on it. Packages that need that SONAME could add "Requires: SONAME-libfoo.so.2". Specific versioning would be tricky, since you can't know the exact versioning a providing package uses. I'm thinking epoch versions might throw a wrench in there... Also that the SONAME "version" number and the package version number (even just the "upstream" part) aren't always numerically the same.
Since everyone should already be using dh_makeshlibs / dh_shlibdeps, this might not even be too hard to prototype...
Posted May 31, 2019 14:58 UTC (Fri)
by patrakov (subscriber, #97174)
[Link]
Posted Jun 6, 2019 9:38 UTC (Thu)
by hensema (guest, #980)
[Link]
Rpm is using cpio as its archive format. Equally arcane as ar, but it does enable you to extract an rpm on foreign systems.
> Also, most of the linux installation professionals I know hate rpm with a passion and would much rather work with deb packages, for a host of reasons not directly relating to the file format itself.
So what you're saying it's better to invent a new format to avoid hurting feelings of those "professionals"?
Let's face it: Debian can still be Debian even if they switch their underlying package format to RPM. Or any other vaguely modern package format.
Refactoring .deb is a good thing, but it does make sense to shop around for existing solutions that work, are mature and maintained.
Posted Jun 10, 2019 6:33 UTC (Mon)
by ceplm (subscriber, #41334)
[Link]
You know that's like twenty years out-of-date complaint, right? And the only meaning of the word "intuitive" is "what I am used to and I hate anything changing", right?
Posted May 28, 2019 22:08 UTC (Tue)
by amacater (subscriber, #790)
[Link] (16 responses)
You can't do that with rpms - and anyway "whose version of rpm" - I'm old enough to remember when Red Hat broke rpm such that you couldn't install updates, when Mandriva introduced a "newer" version of rpm that was a fork by an erstwhile maintainer, that OpenSUSE rpms don't work well with anyone else's.
Debian's strict policy on packaging and upgrades is what makes seamless upgrade from say, Debian 7 to Debian 9 remotely possible: if you're _really_ lucky, you might just be able to upgrade CentOS 6.8 to 7 or 7.6 to 8 but the rpm world is a reinstall to fix every problem.
Debian and Ubuntu share very similar package formats: Ubuntu developers do things differently at times with versions of gcc or whatever so you can't drop Debian and Ubuntu packages together: but you can easily use the source to rebuild them readily.
Disclaimer: I'm a Debian developer but a CentOS and Red Hat sysadmin advising engineers in my day job.
If you _really_ need more than 9GB in a single .deb, chances are that you're doing it wrong even now.
Posted May 29, 2019 0:26 UTC (Wed)
by kfox1111 (subscriber, #51633)
[Link] (11 responses)
I tried some weird experiments many years ago with the alien package converter. Installed redhat using the debian installer (And I think the storm linux installer...). Also installed debian using anaconda. There isn't a huge difference between rpms and debs at the end of the day.
Its what you put in them that counts. :)
Posted May 29, 2019 0:48 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
You sure can. I have done that. rpm2cpio and convenience scripts like rpmls (part of rpmdevtools) make this really easy.
> if you're _really_ lucky, you might just be able to upgrade CentOS 6.8 to 7 or 7.6 to 8 but the rpm world is a reinstall to fix every problem.
Certainly hasn't been the case for years. Many RPM distributions support a straightforward upgrade path.
The complications in enterprise distributions have not much to do with RPM the package format or even the tooling (c.f: things like dnf system upgrade) but the fact that these distributions have a very long lifecycles (10 to 15 years) and they tend to run many third party applications (including proprietary ones) that are brittle in the face of OS upgrades. The answer to that has been VM's and containers.
Minor variations in RPM (nearly all distributions have folded back into using RPM4 which has a very active and healthy upstream project now) don't matter as much. There are packaging differences because unlike Debian/ Debian derivatives like Ubuntu, the RPM world has a broad number of distributions which aren't all derived from Red Hat ex: openSUSE and even in such cases, the divergences have steadily gone away with time. The number of patches in say Fedora, mandriva, opensuse etc patches in RPM package itself is pretty low at this point. Even macros have consolidated considerably.
> but you can easily use the source to rebuild them readily.
You certainly can do that with RPM pretty quickly and I have done that for dozens and dozens of packages. Lots of packages in Fedora due it for supporting EPEL and even more do it for things like openbuildservice.
All of these sounds like issues that are outdated at this point.
Posted May 29, 2019 17:48 UTC (Wed)
by wahern (subscriber, #37304)
[Link] (9 responses)
That's not at all fair to Debian packages. You can make do with RPM and the RPM ecosystem (Yum, DNF), but it's still a pock marked hell scape. Here's a good jumping off point for the low-level sins of RPM specifically: https://xyrillian.de/thoughts/posts/argh-pm.html
Posted May 29, 2019 18:53 UTC (Wed)
by domo (guest, #14031)
[Link]
In early 2010's I spend one month trying to figure out the rpm source code in order to
search for 'rrpmbuild' for code reference.
the format is quite complicated for human observer...
whatever the format is (IMO extending ar(5) is not best option, old tools cannot understand
Best would be some new "extensible linux package format" (w/ sane format, no xml etc)
Even I could device such a format, just that no-one would adopt implementation done
Posted May 30, 2019 11:08 UTC (Thu)
by jond (subscriber, #37669)
[Link] (1 responses)
I'm now wondering how much rpm-ostree might side-step this madness, if at all.
Posted Jun 4, 2019 3:56 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
I am not sure I follow what you are wondering about here. The internal low level implementation details of RPM format obviously doesn't affect end users. What matters to end users is functionality like library and file based dependencies or boolean dependencies or weak dependencies etc.
ostree based systems don't use RPM at all and therefore dependencies don't really matter all that much on these systems for end users. What you get is a OS that is constructed and pushed to end users a single "immutable" image and everything else is supposed to be running of containers of some sort. rpm-ostree provides some level of compatibility with traditional RPM packages but the more you use them, the more you move away from the advantages that a immutable base image provides. Instead the recommend path is use wrapper like Fedora toolbox and within that you could just install plain rpm packages.
Posted May 31, 2019 1:15 UTC (Fri)
by bojan (subscriber, #14302)
[Link] (4 responses)
So, RPM has been tinkered with since its inception and now has a whole lot of baggage caused by various design errors, improvements, folks finding ways to bend it in new and useful ways. Shocking stuff. Who would have thought that a package format that is 22 years old would be like that. :-)
More planned, BTW: https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zst...
Posted May 31, 2019 2:18 UTC (Fri)
by wahern (subscriber, #37304)
[Link] (1 responses)
> Who would have thought that a package format that is 22 years old would be like that. :-)
Debian package users! The Debian package format is old and wrinkly, but it has aged incredibly well in terms of forethought and capabilities. The tooling is more complex but that's because the ecosystem is layered. Many of the biggest headaches in the land of Yum and RPM (sections, macros, file contents, dependencies, building, ...) are insurmountable and force everybody and everything to accommodate the limitations. (Ignorance is bliss, though!) For every headache one can identify in the land of .debs and Apt there are *both* dirty hacks and clean changes in approach that resolve them; rarely are you stopped in your tracks with the realization you simply cannot accomplish something functionally.
IMO the Debian packaging ecosystem continues to evolve and improve. There are improvements to the RPM ecosystem, but they asymptotically move RPM toward a wall.
Detailing all the issues here would be impractical (and I don't have the memory for it, only the scars), but if you have time carefully go through the history of the development of Modularity (you may need to use Wayback Machine to see how the project specifications changed) and you'll see how RedHat had to backtrack and literally reinvent Modularity late in the RHEL8 development cycle after they realized they couldn't surmount various limitations to RPM, particularly with regards to build-time and run-time dependency management. I remember a co-worker raving about how awesome it would be and me being incredulous that they could pull it off, and lo-and-behold it turned out that they couldn't.
Posted May 31, 2019 4:20 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
So, I have no idea why folks go on these long rants to point out how everything Debian has an almost saint like quality and everything else is pure junk. The fact is that both systems are in widespread use and they work, each with their own limitations.
Posted May 31, 2019 8:05 UTC (Fri)
by amacater (subscriber, #790)
[Link] (1 responses)
If you keep your Fedora fully maintained then you'll be upgrading every 12 months or so and will lose support for your version at best every 18 months.
Now take a neglected Debian 7 - some two years out of support. Move it to 8 which is on long term support. Move it to 9. [In a month or so, you can move it to 10 when Buster comes out, maybe.] That includes the sysvinit-systemd transfer which needs a reboot. That takes you from kernel 3.10 - 4.4 seamlesly and 4.19 next month. Oh, and for fun, do this with no network access. You might do this with CentOS: you _can_ do this with DVD images and Debian :) [And yes, it's an "uphill, both ways in the snow" kind of story - but it's real, and there are lots of machines out there that are "only" two years out of support and have to be maintained and upgraded without data loss. ].
Posted May 31, 2019 8:49 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Red Hat decided they didn't want to support upgrades from RHEL 5 to 6, but 6 to 7 (for some products) and from 7 to 8 is possible:
https://access.redhat.com/solutions/637583
Posted May 31, 2019 8:30 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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.
Posted Jun 3, 2019 22:22 UTC (Mon)
by logang (subscriber, #127618)
[Link]
Posted Jun 6, 2019 8:55 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
> Debian's strict policy on packaging and upgrades is what makes seamless upgrade from say, Debian 7 to Debian 9 remotely possible: if you're _really_ lucky, you might just be able to upgrade CentOS 6.8 to 7 or 7.6 to 8 but the rpm world is a reinstall to fix every problem.
What you miss here, is that (afaik) all distros that use deb are DERIVATIVES of debian, so they inherited debian's packaging rules.
OpenSUSE (at least its parent) PREDATES rpm, heck iirc it even predates Red Hat, so while it adopted the rpm program and file format, it already had its own, completely different, packaging rules.
Things are a lot better on that front now, I believe ...
(SuSE began as a Slackware derivative, then was derived from some other obscure distro, then became its own master.)
Cheers,
Posted Jun 6, 2019 19:42 UTC (Thu)
by amacater (subscriber, #790)
[Link] (1 responses)
Deb "just works" but only because Debian puts a whole lot of policy in place and developers are constrained to work so that packages co-install, don't overwrite libraries from other packages and so on. It's hard nosed packaging policy that makes it work. [A colleague says "CentOS just downloads it's easy - Debian's too big!" but that's because Debian includes the world and its source ]
Posted Jun 6, 2019 20:50 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
I agree with that view. That has nothing to do with the format of the archive. It is much more higher level.
>"CentOS just downloads it's easy - Debian's too big!"
Not sure what that means. Net installation works just fine in either.
Improving .deb
Improving .deb
Improving .deb
Improving .deb
Improving .deb
Improving .deb
I've been using both for ~24 years.
Improving .deb
Improving .deb
Improving .deb
rpm pains (orig: Improving .deb)
make it working elsewhere. While doing that I got some knowledge about the format,
and then got good enough replacement made using perl(1)
it anyway, so something better could be deviced) it should be simple enough everyone
can easily do their own tools (or help extending the existing ones).
which could be adopted by all distributions. the format would have extensible package
metadata format, and then extensible file (metadata, including file contents) format.
by random programmer very often...
Improving .deb
Improving .deb
Improving .deb
Improving .deb
Improving .deb
Improving .deb
Improving .deb
https://access.redhat.com/documentation/en-us/red_hat_ent...
Improving .deb
Improving .deb
Improving .deb
Wol
Improving .deb
Improving .deb