Bug 697327

Summary: Xorriso duplicates system libraries and links them static
Product: [Fedora] Fedora Reporter: Robert Scheck <redhat-bugzilla>
Component: xorrisoAssignee: Juha Tuomala <tuju>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: a.badger, metherid, tuju
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
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:
Cloudforms Team: ---
Bug Depends On: 697326    
Bug Blocks: 504493, 680109    

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

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

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.