Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 697327 - Xorriso duplicates system libraries and links them static
Summary: Xorriso duplicates system libraries and links them static
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorriso
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Juha Tuomala
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 697326
Blocks: DuplicSysLibsTracker 680109
TreeView+ depends on / blocked
 
Reported: 2011-04-17 18:58 UTC by Robert Scheck
Modified: 2011-12-05 19:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-05 19:53:13 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.