This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 697327 - Xorriso duplicates system libraries and links them static
Xorriso duplicates system libraries and links them static
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorriso (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Juha Tuomala
Fedora Extras Quality Assurance
:
Depends On: 697326
Blocks: DuplicSysLibsTracker 680109
  Show dependency treegraph
 
Reported: 2011-04-17 14:58 EDT by Robert Scheck
Modified: 2011-12-05 14:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-05 14:53:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2011-04-17 14:58:47 EDT
Description of problem:
The xorriso package is the GNU xorriso package which duplicates the system
libraries libisofs, libburn and libisoburn in order to produce a statically
linked xorriso binary. This violates from my point of view the following
parts of the Fedora Packaging Guidelines:

 - http://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries
 - http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

The solution is to switch from the GNU xorriso to the Libburnia xorriso, which
provides an xorriso using the system libraries without any static linking. The
xorriso

Version-Release number of selected component (if applicable):
xorriso-1.0.0-2.fc15

Actual results:
Xorriso duplicates system libraries and statically links them

Expected results:
No duplication of system libraries and no static linking anymore.

Additional info:
Red Hat Bugzilla #697326 contains a review request for libisoburn which is then
providing a dynamically linked xorriso so that this xorriso package can simply
be orphaned afterwards (on all branches).
Comment 1 Juha Tuomala 2011-04-18 07:38:12 EDT
I think there used to be an issue compiling 64-bit version which was avoidable with statical linking.

If it would be dynamically linked, it would have to be maintained synchroniously which might not be a bad idea. I'm just wrong person for that.

So, if you want to maintain xorriso, go ahead. If not, let's close this as NOTABUG.
Comment 2 Rahul Sundaram 2011-04-18 07:51:29 EDT
If you can't maintain it according to the packaging guidelines, either get a exception from FESCo or orphan it and let someone else do it.  Ignoring the guidelines is not a option.
Comment 3 Robert Scheck 2011-04-18 08:05:02 EDT
Once again, there are two different flavours of xorriso and a) is in Fedora,
thus this bug report:

a) GNU xorriso: libisofs+libburn+libisoburn+xorriso (static linked)
b) Libburnia xorriso: libisoburn+xorriso (dynamic linked)

Bug #697326 is a review request for Libburnia xorriso. Once the new libisoburn
package is reviewed, xorriso package can be obsoleted, because the libisoburn
package will provide dynamic linked xorriso as a subpackage.

All I need is a reviewer for libisoburn and Juha neends to orphan his package
in pkgdb according to the Fedora Packaging Guidelines. If last not happens, I
will force it via FESCo as there is no real reason for an exception...

Nevertheless Juha, you're free to do the package review and get a libisoburn
co-maintainer, if you would like to be in charge for xorriso further on.
Comment 4 Michael Schwendt 2011-10-05 05:52:39 EDT
> xorriso package can be obsoleted

Retiring it properly would be sufficient, since libisoburn's xorriso subpackage EVR is higher.
Comment 5 Toshio Ernie Kuratomi 2011-12-05 14:53:13 EST
Package EOL procedures have been done for this package.  No blocking requested from rel-eng because I think libisoburn's xorriso subpackage will supercede this properly and I didn't see any xorriso SRPMS in a quick look at the mirrors.

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