Ticket #219 (closed: fixed)
Bundled lib exception request for libtidy bundled with sigil
|Reported by:||jwrdegoede||Owned by:||spot|
|Priority:||normal||Component:||Bundled Library Exception|
I've been working on packaging sigil (an epub editor) for a while now, see: https://bugzilla.redhat.com/show_bug.cgi?id=772362
sigil initially used a ton of bundled libs. Luckily upstream was very helpful in modifying sigil to use system versions of these, so the latest upstream release can use system versions of all libs used except for libtidy, where upstream and I are in agreement that Sigil should stick to using its own modified copy.
Sigil's use of libtidy is special because libtidy is an html code cleanup library, which sigil uses to cleanup epub sources, which are similar to html but not exactly the same.
Because of this sigil's copy has several behavioral changes, which makes it a different beast from the system version of libtidy, and adding these behavioral changes to the system copy is undesirable. Some examples are: 1) Sigil's libtidy versions does case insensitive attribute name matching versus case sensitive for the system copy 2) Sigil's libtidy versions accepts a : in places where a ; should be used 3) Sigil's libtidy versions lowercases attribute names in the cleaned up output 4) Sigil's libtidy version automatically cleans up several errors where the system version only warns about them
These together make Sigil's copy almost another beast entirely...
About the questions from the wiki page:
- Has the library behaviour been modified? If so, how has it been modified? If the library has been modified in ways that change the API or behaviour then there may be a case for copying.
- Could we make the forked version the canonical version within Fedora? For instance, if upstream for the library is dead, is the package we're working on that bundles willing to make their fork a library that others can link against?
No, as it changes behavior quite a bit and this may break existing users of libtidy
- Are the changes useful to consumers other than the bundling application? If so why aren't we proposing that the library be released as a fork of the upstream library?
Sigil's author is also the author of an epub validation lib, called flightcrew: http://code.google.com/p/flightcrew/
For which he has deliberately created a separate upstream so that it can be used by other apps. Therefor I believe that if his modified libtidy copy ever grows into something generally usable he will likely release it as a separate project too.
- Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release?
They are fully in sync with the latest libtidy upstream (which is quite old)
- What is the attitude of upstream towards bundling? (Are they eager to remove the bundled version? are they engaged with the upstream for the library? Do they have a history of bundling? Are they argumentative?)
Upstream has been very helpful in and supportive of merging patches to use system copies of libs where ever possible.
- Overview of the security ramifications of bundling
libtidy is used to parse epub code which could come from potential hostile sources. But given that libtidy upstream seems dead, security fixes are more likely to come in through Sigil itself, rather then the system copy getting fixes which Sigil's copy will miss.
- Does the maintainer of the Fedora package of the library being bundled have any comments about this?
I'll send him a mail asking him to leave his feedback in this ticket.
- Is there a plan for unbundling the library at a later time?
- Owner set to spot
- Status changed from new to assigned