Ticket #202 (new task)

Opened 20 months ago

Last modified 12 months ago

Application for exemption from "No bundling" rule: Gargoyle

Reported by: carlo Owned by:
Priority: minor Milestone:
Component: Bundled Library Exception Version:
Keywords: gargoyle Cc: ktdreyer
Blocked By: Blocking:

Description

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.

Change History

comment:1 Changed 20 months ago by ktdreyer

  • Cc ktdreyer added

As one of the reviewers in the BZ ticket, I can say that Carlo's been very responsive so far (over a year!), and I think that could count towards his reputation for this.

comment:2 Changed 20 months ago by toshio

support/babel is also bundled: http://babel.ifarchive.org/program.html

Appears to be a set of programs to match metadata with interactive fiction data.

comment:3 Changed 20 months ago by toshio

I had a false alarm about a bundled font too. From README.fedora: "Bitstream Charter fonts (modified by Tor Andersson for Garglk)"

It looks like the remove-luximono-font.patch also removes the bundling of BitStream? Charter. I'm inclined to think this is a good thing. Probably should do the following:

  • Remove the bitstream Charter section of README.fedora
  • In %prep: rm -rf fonts/ # Remove bundled fonts
  • rename the remove-luximono-font.patch to disable-bundled-fonts.patch
  • Add a comment to the spec file saying that the patch makes gargoyle use system fonts instead of the bundled fonts.

comment:4 Changed 20 months ago by toshio

Okay -- I've done a little bit of testing of this. I set it to not build any terps. Then I built the scare terp from upstream. scare has several frontends -- The build script might need to be massaged somewhat to build all the frontends but it does, by default have separate prefixes for different types of frontend (there's "scare" for the terminal version and glkscare for the glk frontend).

It looks like it would be possible to build the glk version with multiple different glk libraries but I'm not sure if those libraries are ABI compatible or only API compatible. The library that provides the glk api is also not the only boilerplate that is needed. There's a small bit of boilerplate to start the program (and provide the main() function) that it looks like the various glk implementations provide as a separate static library.

Once built, the scare interpreter does need to use libgarglk.so to run but does not need to be run via the gargoyle frontend. ./glkscare [STORY_FILENAME] works fine.

I don't think I could vote for bundling of several of these classes of terps under the current guidelines. However, I could see us relaxing the guidelines to allow for bundling of some class of code that includes this. I just want the guidelines to be fair for anyone who wants to do something similar.

comment:5 Changed 20 months ago by laxathom

Agreed with your statement.

comment:6 Changed 13 months ago by limb

Please update this ticket regarding its continued relevance, providing any information requested. If this is not done within the next two weeks, this ticket may be closed due to inactivity. Thank you!

comment:7 Changed 12 months ago by ndroftheline

Hello,

I am very new here so please excuse my obvious bump, but I am a development worker trying to put up a MultiSeat? computer system for a high school in the Philippines, and a program like Gargoyle could be *really* helpful to provide the kids with fun activities - interactive fiction is the exact kind of thing that would work brilliantly here.

So I apologize for not contributing anything at all to the official discussion on the review, this seems like a worthwhile project to keep pushing.

Note: See TracTickets for help on using tickets.