On Tue, Jan 25, 2011 at 06:59:08PM +0000, Roger Leigh wrote:
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-devmaintained 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).
Thanks for the insight! 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.
Yes, I know that this was tried in the past, and I have not yet decided to try it out again, just considering, so far...
- Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: Digital signature