[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Provide libijs packages as a binary package of Ghostscript?

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).


  .''`.  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

Reply to: