#219 Bundled lib exception request for libtidy bundled with sigil
Closed: Fixed None Opened 11 years ago by jwrdegoede.

Hi,

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.

See above.

  • 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?

No


FPC looked at but did not vote on this request at this week's meeting. There were two areas that we had questions about. Looking at the diff in bugzilla between the bundled version and upstream some of the changes looked generally applicable (for instance, the uint casting). The behavioral changes we wondered if they could be merged with upstream using a flag in the relevant functions to specify which behaviour was desired (for cleanup vs warning, it seems like tidy might have a warn vs clean mode already).

It was noted that tidy itself looks either dormant or dead upstream. There are two known forks, tidyp which is also dormant or dead, and tidy-html5 which is more recently active. FPC wondered if sigil upstream could work with tidy-html5 to get these changes added, take over one of the dead projects, or create a new fork dedicated to epub.

just a note - the bundled tidy was modified by the original Sigil author, who is not active for quite some time

Bundling exception approved (+1:5, 0:0, -1:2).

Sharkcz, please ask the Sigil upstream to strongly consider maintaining their fork of libtidy as an independent component.

Also remember to add virtual provides for the bundling. I've added '''bundled(libtidy)''' to https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions for this purpose.

announcement writeup:

Sigul was granted an exception to bundle libtidy due to the bundled libtidy being modified to handle epub files. Sigul upstream is to be asked to consider making their fork a publically linkable library so that others can use it on epub files as well.

Thanks for the exception! We (me and Dan) or working on moving the review forward and getting Sigil into Fedora.

p.s. About the announcement writeup, it is Sigil not Sigul !

Metadata Update from @toshio:
- Issue assigned to spot

7 years ago

Login to comment on this ticket.

Metadata