Red Hat Bugzilla – Full Text Bug Listing
|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>|
|Version:||rawhide||CC:||a.badger, metherid, tuju|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-12-05 14:53:13 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|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 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.