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:
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.