Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 529379

Summary:	RPM should be compiled statically for safety
Product:	Red Hat Enterprise Linux 5	Reporter:	Graham Leggett <minfrin>
Component:	rpm	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.3	CC:	n3npq, pmatilai
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-07 10:13:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Graham Leggett 2009-10-16 13:54:32 UTC

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.

Comment 1 Jeff Johnson 2009-10-16 17:43:28 UTC

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.

Comment 2 Panu Matilainen 2013-03-07 10:13:56 UTC

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.