Red Hat Bugzilla – Bug 697327
Xorriso duplicates system libraries and links them static
Last modified: 2011-12-05 14:53:13 EST
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:
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):
Xorriso duplicates system libraries and statically links them
No duplication of system libraries and no static linking anymore.
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).
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.
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.
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.
> xorriso package can be obsoleted
Retiring it properly would be sufficient, since libisoburn's xorriso subpackage EVR is higher.
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.