I've been working on packaging sigil (an epub editor) for a while now, see:
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:
No, as it changes behavior quite a bit and this may break existing users of libtidy
Sigil's author is also the author of an epub validation lib, called 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.
They are fully in sync with the latest libtidy upstream (which is quite old)
Upstream has been very helpful in and supportive of merging patches to use system copies of libs where ever possible.
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.
I'll send him a mail asking him to leave his feedback in this ticket.
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.
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
to comment on this ticket.