Ticket #202 (new task)
Application for exemption from "No bundling" rule: Gargoyle
|Reported by:||carlo||Owned by:|
|Component:||Bundled Library Exception||Version:|
I'd like to apply for an exemption to the "No Bundled Libraries" rule for the "gargoyle" package that I'm trying to get reviewed. Gargoyle is an interpreter for interactive fiction ("text adventure") story files that supports several different formats, by including a separate interpreter executable for each format. Each of these interpreters uses the Glk I/O layer; some had to be modified to this end. Gargoyle includes its own implementation of the Glk specification, called Garglk, and each interpreter is dynamically linked against Garglk. (So in fact this is a case of bundling applications, not libraries.)
I'm arguing that it makes sense to package Gargoyle as-is as a Fedora package. The bundled interpreters (aka "terps") fall into a few different categories (this information is as best I could determine):
- (I) No upstream exists; Glk port due to Gargoyle
- ScottFree (Scott Adams games terp)
- (II) No upstream exists, or it is unmaintained; source exists at the IF Archive, including Glk version
- (III) Upstream is alive; Glk port is due to Gargoyle
- (IV) Upstream is alive and include Glk version, but less up-to-date than Gargoyle-bundled version
- (V) Upstream is alive and includes Glk version; release version matches Gargoyle-bundled version
- (VI) Terp cannot be included in Fedora package due to license problems
Note furthermore that there is no Fedora package for any of these terps. Therefore, there is no duplication of code within Fedora. The only exception to this is Frotz, whose Fedora package only has a terminal (ncurses-based) UI; the Gargoyle version adds both a Glk layer and various other features, so is in fact a fork at this point.
Could we separate out the category (V) terps and package these separately? Not without modifications to Gargoyle, which has no capability to determine at runtime which terps are available, although this would admittedly not be too difficult to add. Alternatively, it might be possible to base the Fedora package for Gargoyle on the upstream versions of the category (V) terps, in case these are more recent than the ones bundled with Gargoyle. But the presence of category (IV) shows that Gargoyle may in fact have the most up-to-date version of an interpreter, so we would really have to check both Gargoyle and upstream and take the later version, and also look out for any patches that Gargoyle has applied to its bundled versions.
This would be possible, but to me does not seem worth the effort, given that Gargoyle has a good track record of closely following upstream for its bundled terps; also, the security aspect of not receiving the latest upstream patches does not seem very pertinent here (nothing runs as root, no setuid bits, niche appeal).
Below I include answers to the "standard questions" in the guidelines. Because the controversial part here is the inclusion of the interpreters, not of the Garglk library, I've re-interpreted the questions as referring to the bundled terps when it says "library".
- Q: Has the library behaviour been modified? If so, how has it been modified?
- A: At a source level, terps in categories (I) and (III) were modified to add Glk support, while no or only minor modifications were made for terps in categories (II), (IV) and (V). The build procedure for all terps has been changed to link dynamically against the Garglk library that forms the heart of Gargoyle.
- Q: Why haven't the changes been pushed to the upstream library?
- A: For terps in category (I) and (II), because no upstream exists. For category (III) terps, presumably because the Gargoyle maintainer (Ben Cressey) did not want to burden the respective terp maintainers with the significant change of a port to Glk.
- Q: Have the changes been proposed to the Fedora package maintainer for the library?
- A: Apart from Frotz, none of the terps are currently packaged for Fedora. I have not contacted the Frotz maintainer, but it would not seem to make much sense to create a separate frotz-glk package which is derived from upstream Gargoyle and has to depend on garglk, also derived from upstream Gargoyle. It might be possible to create a common codebase out of upstream Frotz and Gargoyle Frotz, combining their ncurses and Glk capabilities (choosing one at compile-time), but that would be up to the Frotz and Gargoyle maintainers, and probably not high on their priority list.
- Q: Could we make the forked version the canonical version within Fedora?
- A: Yes, that is in effect what I am proposing for all those terps which do not exist within Fedora. For Frotz, it does not seem a bad thing to have both an ncurses-based version and a garglk-based version.
- Q: 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?
- A: The idea of the Glk specification is that a terp using Glk can be linked against any library implementing the Glk standard. So, yes, we could package each terp separately and have it depend on any Glk-implementing library. At the moment, however, there is no other such library in Fedora. There do exist some others upstream apart from garglk which we could package; there is even one that allows choosing the Glk library at runtime, which would enable an /etc/alternatives-based approach. One would have to think about how the Gargoyle frontend could fit in, which assumes that it has Garglk available. On the whole it does not seem worthwhile though.
- Q: Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release?
- A: Gargoyle seems pretty good at following upstream for each of its terps; it currently is not lagging behind for any of them.
- Q: What is the attitude of upstream towards bundling?
- A: See a quote from Ben Cressey, the Gargoyle maintainer.
- Q: Overview of the security ramifications of bundling
- A: IF interpreters have not been known for their security flaws; as mentioned above, no root privileges or setuid bits are involved, and not many people are interested in them in the first place. Moreover, Gargoyle has displayed a good track record of following upstream for its bunded terps.
- Q: Does the maintainer of the Fedora package of the library being bundled have any comments about this?
- A: I have not contacted the maintainer of the Frotz package (Chris Grau, Fedora account name cgrau). However, that package is based on the regular upstream Frotz, while Gargoyle's Frotz is effectively a fork, including not only Glk support but also various other enhancements.
- Q: Is there a plan for unbundling the library at a later time?
- A: Not until interactive fiction becomes so popular that having multiple Glk-implementing libraries is seen as a must.
- Q: Please include any relevant documentation -- mailing list links, bug reports for upstream or the bundled library, etc.
- A: See my request to get Gargoyle into Fedora, the Gargoyle website, the Garglk website (note, Garglk is developed as part of Gargoyle), the Gargoyle development mailing list, the Glk website