On Mon, Jan 24, 2011 at 08:47:07PM +0100, Jonas Smedegaard wrote: > Hi Till (and others), > > I took the liberty of moving this conversation to the Debian Printing > Team and cc ijs package maintainer. > > On Mon, Jan 24, 2011 at 08:12:31PM +0100, Till Kamppeter wrote: >> as written on >> >> http://www.openprinting.org/download/ijs/ >> >> the current head of development of the IJS code is in Ghostscript and >> not on OpenPrinting. >> >> So to keep the binary packages >> >> - libijs-0.35 >> - libijs-dev >> >> maintained with the up-to-date source code I suggest to remove the >> "ijs" source package from Debian and build the IJS library using the >> ijs/ directory of Ghostscript (naturally then not removing it from >> Ghostscript when repackaging the source tarball). >> >> See also >> >> http://bugs.ghostscript.com/show_bug.cgi?id=691904 >> >> WDYT? > > I dislike treating Ghostscript as source of multiple libraries! > > I think that a) ijs package should cherry-pick from ghostscript sources > (manually, from upstream tarballs and/or VCS), and b) ijs package > maintainers (or anyone, really - perhaps yourself?) verify if current > ijs upstream truly is dead or have sane reason to not adopt what is > currently shipped with ghostscript. When those options are tried, we > can discuss if perhaps we shoulf try convince Ghostscript developers to > release their library as separate tarballs. > > As a related note, I recommend ijs package maintainer to join the Debian > Printing Team to ease coordination like this. :-) 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). 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