RPM should be compiled statically for safety

[Jeff Johnson]

tracker

[Graham (graham-redhat-bugs)]

Description of problem:

RPM is currently compiled dynamically, against a long list of dependencies that is invisible to an administrator.

If the administrator removes one of these dependencies to temporarily work around a problem (in this example, sqlite, to work around the error "package sqlite-3.5.9-2.x86_64 (which is newer than sqlite-3.3.6-2.i386) is already installed:), rpm dies as follows:

rpm: error while loading shared libraries: libsqlite3.so.0: cannot open shared object file: No such file or directory

While the system can be hacked to work around it, it would be far safer if rpm was tolerant of this by being statically linked against packages it depends on.

[Jeff (jeff-redhat-bugs)]

Yes. Exactly. Totally agreed.

The technical issue that needs solving for RPM to again be linked
with -all-static (which was always done for years) has to do with
how locks are implemented.

RPM (and specifically and rpmdb) currently uses POSIX(optional) shared
mutexes. The main engineering reason why that is/was the right choice
is that interprocess and interthread locks can use the same underlying
locking scheme.

But (as implemented in glibc) POSIX shared mutexes are implemented
through NPTL primitives on top of kernel futex primitives.

For RPM to return (easily, the entire locking scheme could be reworked for RPM too)
to being linked with -all-static, then glibc must provide POSIX(optional)
shared mutexes for static as well as dynamic linking. Historically, since almost
no programs (other than RPM) have needs of static linking, providing NPTL
through static linking has not been a priority afaik. There are some extremely
difficult engineering issues that need to be resolved and supported in glibc
reliably in order for RPM to be statically linked and continue using POSIX(optional)
shared mutexes for rpmdb locking primitives.

Disclaimer: These are historical details, the current state-of-affairs may be
quite different than what I am describing here.

[Panu (panu-redhat-bugs)]

This request was evaluated by Red Hat Engineering for inclusion in a Red Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this change in a Red Hat Enterprise Linux update release for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.

While having rpm statically linked seems like a good idea, there are technical reasons requiring rpm to be dynamically linked and that has not changed nor are they expected to change in future releases. Anaconda rescue mode can be used for disaster recovery.