Bug 697327

Summary:	Xorriso duplicates system libraries and links them static
Product:	[Fedora] Fedora	Reporter:	Robert Scheck <redhat-bugzilla>
Component:	xorriso	Assignee:	Juha Tuomala <tuju>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	a.badger, metherid, tuju
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-05 19:53:13 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:
Bug Depends On:	697326
Bug Blocks:	504493, 680109

Description Robert Scheck 2011-04-17 18:58:47 UTC

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 11:38:12 UTC

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 11:51:29 UTC

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 12:05:02 UTC

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 09:52:39 UTC

> 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 19:53:13 UTC

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.