Bug 158537 - LSB packaging with shared libraries is impossible to achieve.
LSB packaging with shared libraries is impossible to achieve.
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-23 09:25 EDT by Jeff Johnson
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-27 02:49:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 2005-05-23 09:25:48 EDT
Description of problem:

RPM generates a
    Requires: /path/to/interpreter
(usually /bin/sh) whenever a package scriptlet is present.

This makes it impossible to generate LSB compliant packages with
any version of rpm.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Miloslav Trmač 2005-05-23 11:50:03 EDT
http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/swinstall.html
says that /bin/sh is an allowed dependency.
Comment 2 Jeff Johnson 2005-05-23 11:54:38 EDT
So s/scriptlets/libraries/ with ldconfig exec. Producing LSB compliant
packaging is neqrly impossible.
Comment 3 Miloslav Trmač 2005-05-23 12:02:33 EDT
Replacing
 %post -p /sbin/ldconfig
with
 %post
 /sbin/ldconfig
seems easy - what am I missing?
Comment 4 Jeff Johnson 2005-05-23 12:11:28 EDT
You miss that certain packages -- like glibc -- must be installed
before /bin/sh is present.

The LSB standard also has little clue of multilib and the necessary tags
to achieve an install. The problem in general cannot be specified by
dictating format and content, the semantic interpretation needs to be
"standard" as well.
Comment 5 Paul Nasrat 2005-05-23 12:27:52 EDT
Surely we can address this within the appropriate standards groups. 

Note that upstream rpm changes such as dropping RPMSENSE_PREREQ also break LSB
compatibility. 
Comment 6 Jeff Johnson 2005-05-23 13:36:27 EDT
Not setting a bit in a field should not break standards comnpliance.
And LSB has *never* attempted a semantic intetrpretation of
metadata content values, only forbidding values afaik.

Specific pointer to LSB doco where RPMSENSE_PREREQ presence in
*.rpm header is mandated please, and I will open another bug.
Comment 7 Jeff Johnson 2005-05-23 13:38:12 EDT
And feel free to approach solutions within appropriate
"standards" efforts. I have done that for years and years
to no avail.

Note You need to log in before you can comment on or make changes to this bug.