On Tue, Jan 25, 2011 at 08:27:38PM +0100, Jonas Smedegaard wrote: > On Tue, Jan 25, 2011 at 06:59:08PM +0000, Roger Leigh wrote: >> I was the original packager and maintainer of ijs, and I was also >> involved with upstream when it was created, so I might be able to >> provide some insight here. I was also the one who added autotools and >> shared library support upstream. >> >> IJS implements a transport protocol between a client (ghostscript) and >> a server (printer driver) to allow ghostscript to use drivers not >> hard-coded in the ghostscript sources. This allows it to use >> out-of-tree drivers such as gutenprint. >> >> Early on, ghostscript decided to import the sources directly into their >> tree rather than linking with the actual libijs library; I forget the >> exact rationale for this. Initially the ijs sources were not usable as >> a "real" library--I had to make it into a shared library since >> initially it was only usable by embedding. IJS is basically complete >> and will not change: the protocol is defined and there's no reason to >> touch the code bar bugfixing, and that's been done. So ghostscript >> doesn't need to continually track new releases. >> >> However, this is a *client-server* model. ghostscript is the client; >> anything else could be a server. Unless the server also does the >> embedding of the ijs sources, it will need to link with libijs; it >> can't use the internal ghostscript copy, since ghostscript doesn't >> build it as a library--it's just linked in. >> >> My take on this is that there are these solutions: >> 1) ghostscript removes the embedded ijs copy and links with libijs >> Any fixes in the ghostscript copy should be applied to libijs. >> 2) ijs is removed >> ghostscript's copy will be the canonical source, and ghostscript >> will build this as a shared library and link with it; other >> programs will be able to use it. >> >> I would ordinarily prefer (1), but given that ijs is /de facto/ >> specific to ghostscript (there are no other ijs clients to my >> knowledge) I can't see a problem with it being provided by ghostscript, >> so long as it makes a proper shared library and provides the same >> pkg-config support etc. This is basically to ensure it's as usable by >> third parties as the existing libijs (which I made usable so that this >> was possible). > > Thanks for the insight! Just for the record, I think there should be *one* copy of ijs only. I really don't care whether it's in ijs or gs. However, given that gs is required for ijs to work, and the copy in gs has had some maintenance, I think the gs copy would be the better choice (providing it can be made usable for others). They are probably the effective upstream maintainers of the code in any case given the complete lack of upstream ijs activity for years. [The upstream were the gs maintainers (more or less) in any case.] I did try to hack on getting gs to do this back in 2002, but gs was so baroque I couldn't make any headway. If it's easy to get the gs build system to build and link with a shared lib, and generate the .pc file, that would be great. It just needs someone familiar with gs. (I remember the horror of when gutenprint (then gimpprint) was also embedded wholesale in the gs tree as gdevstp; it was imported regularly from our CVS, and it make it hard to develop since it was so fragile and we had to make sure our Makefiles stayed compatible with the gs tree. IJS was a Godsend since it allowed us to be entirely separate.) IMO the wholesale embedding of stuff in gs is a symptom of wider issues in gs (the number of embedded drivers is horrifying--they should all have been made modular years back, which would prevent stupid stuff like having to have gs linked with X etc.). > Another argument for keeping libijs separate: > > I consider packaging GNU Ghostscript, which seem to have a slightly > different development pace and thus might be interesting e.g. for > security concerned users, and would also make the recent RC issue of > ghostscript less dramatic, as there would be the option of ripping out > one of the implementations temporarily, if multiple ones were available > to choose from. Have there been any gs issues related to ijs? AFAICT, they directly copied the IJS sources files straight into their tree, so any issues should be present in both packages. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature