I'd like to apply for an exemption to the "No Bundled Libraries" [http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries rule] for the "gargoyle" package that I'm trying to get [https://bugzilla.redhat.com/show_bug.cgi?id=682544 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 [http://www.eblong.com/zarf/glk/glk-spec-074_0.html 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):
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 [http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries 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".
'''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 [http://www.eblong.com/zarf/glk/ garglk] which we could package; there is even [http://www.ifarchive.org/if-archive/programming/glk/implementations/glkloader-0.3.2.tar.gz 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 [https://bugzilla.redhat.com/show_bug.cgi?id=682544#c15 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.''
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.
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.
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:
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.
Agreed with your statement.
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!
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.
I'm going to bump this back to meeting in light of our more recent rules on approving bundling exceptions. This certainly seems to me to fall under the "too insignificant to care" rule. Which I don't think we actually wrote down anywhere, unfortunately.
We talked about this at today's meeting (http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-12/fpc.2015-02-12-17.05.txt):
Metadata Update from @laxathom: - Issue assigned to tibbs
Login to comment on this ticket.