Improving .deb

Posted May 28, 2019 21:27 UTC (Tue) by compenguy (guest, #25359)
In reply to: Improving .deb by jhoblitt
Parent article: Improving .deb

> Is there a technical argument for why it makes more sense to massively refactor Deb instead of just switching to rpms?

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.

Improving .deb

Posted May 30, 2019 15:50 UTC (Thu) by imMute (guest, #96323) [Link] (1 responses)

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

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

Improving .deb

Posted May 31, 2019 14:58 UTC (Fri) by patrakov (subscriber, #97174) [Link]

In this particular case, there is a policy how to name packages providing shared libraries, and a lintian check that enforces it. E.g., under this policy, a package that provides libncurses.so.6 must be named libncurses6. So this is a case of convention over configuration, but the end result is the same.

Improving .deb

Posted Jun 6, 2019 9:38 UTC (Thu) by hensema (guest, #980) [Link]

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

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.

Improving .deb

Posted Jun 10, 2019 6:33 UTC (Mon) by ceplm (subscriber, #41334) [Link]

> The state management for package install/upgrade/uninstall is more robust and intuitive for deb being one of the really big ones.

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?