(Ghostscript folks, we're starting to talk about splitting up the
Gimp-Print project into sub-components.)

   From: Eric Sharkey <[EMAIL PROTECTED]>
   Date: Fri, 05 Jul 2002 20:26:16 -0400

   My two cents is to spin off what you can provided you can find
   interested new maintainers.  From the point of view of a
   distributor/packager, smaller more self-contained packages are
   easier to handle.  For example, as a Debian maintainer, I can't
   upload to Debian new releases of escputil without also uploading
   new libgimpprint, cups drivers, etc.  Everything that builds from a
   single source tarball has to be updated together.  For most
   packages this isn't a big deal, but for gimp-print it's starting to
   get a little silly.

That's the question I should have asked -- what's the best thing for
the packagers, since core Gimp-print isn't really an end-user
package.  Sounds like you and Till are in rather violent agreement
here.  I'm not sure that that's what I had expected, but it certainly
seems to confirm the idea that it should be split.

Would it make sense to split each of the high-level drivers -- CUPS,
IJS, and traditional Ghostscript -- into its own package?  It sounds
like you and Till both think so.

So with all this, one possibility would be:

1) libgimpprint (including the current src/main, include/gimp-print,
   src/testpattern, test, and the developer's manual).  I think that
   the test pattern generator should be included with libgimpprint as
   a "sample Gimp-Print application".  I imagine that distributors
   would put this into a libgimpprint-devel package, along with
   gimpprint-config, gimp-print.h, and possibly the developer's
   manual.  We might include the sample images here; they'd probably
   go into a developer sub-package since they're most useful for
   people supporting new printers.  The developer tools are included
   in the test directory; we might want to move them within the core
   package (or do we want to split this into libgimpprint and
   gimpprint-utils?).  The Gimp-Print project would clearly own this.

2) gimpprint-cups -- the CUPS driver (rastertoprinter) and PPD
   generator (genppd).  I'm starting to think that we're using genppd
   all wrong -- rather than generate the PPD files into a directory
   within the build tree, and then copy them into the installation
   directory, we should simply generate the PPD files into the CUPS
   PPD area.  This might solve the long-standing translation problem,
   since the message catalogs would already be installed correctly
   into the filesystem, and we wouldn't have to do the silly hack we
   do now.

   It's unclear to me that things like commandtoepson, commandtocanon,
   cups-calibrate, canon, and epson belong in Gimp-print at all.
   These look to be core CUPS functionality, and the potential for
   collision is high.  For that matter, "rastertoprinter" should
   probably be "gimpprint-rastertoprinter" or the like.  Mike?

   Perhaps we would own this, or perhaps the CUPS project would.  CUPS
   is quite stable, although 1.2 is going to have some new and
   interesting stuff.

3) The old-style Ghostscript driver (stp), delivered as a patch to
   Ghostscript.  That is, if we don't want to deprecate this
   altogether in 4.3, now that IJS functionality is reasonably mature
   in GNU Ghostscript.

   I would much prefer to see the Ghostscript project own this.  They
   already have it in 6.53 and newer GNU releases, and we'd just as
   soon get rid of it.

4) The IJS Ghostscript driver.  Other than ownership, this is about
   the most straightforward piece of the lot.  Both Gimp-print and IJS
   are evolving interfaces, so maybe this would need to be a separate
   project maintained by a cross-functional team.

5) Foomatic.  The key here is really the foomatic data generator.  The
   foomatic data generator actually contains a number of Gimp-print
   client applications that extract data from the (internal) database
   via supported interfaces.  Foomatic is also a somewhat evolving
   interface.  Till, any more thoughts about this?  Ownership?

6) escputil and lexmarkutil.  These have nothing to do with
   libgimpprint at all and don't even link against it.  We've owned
   these because we wrote them, but they would really fit much better
   with mtink if Jean-Jacques wants to take them in.

7) The Gimp Print plugin.  This one's a real hairball.  We own it
   largely for legacy reasons.  It is currently a client of
   libgimpprint, but as a result there are a number of design
   decisions in libgimpprint that wouldn't have been made otherwise
   (such as the way image position and size are specified, the way the
   color functions are exposed, and the presence of the Postscript
   family driver).  There are real issues of ownership, what it should
   be, and whether it should even be a libgimpprint client at all.

8) The user manual.  A lot of its raison d'etre goes away if we split
   everything off, since then Gimp-print won't even be a user-visible
   package at all.  However, there's far too much good work there for
   it to go away.  Perhaps it needs to split up, and the Gimp portions
   should go with the Gimp plugin, the CUPS portions should be
   absorbed by the generic CUPS documentation, and the escputil
   portion should go with escputil.

Thoughts?  This is a fairly radical proposal in some ways.  However,
the current 4.3 API is still completely compatible with 4.2, and
perhaps we should do a 4.4 that's simply 4.2 (or 4.3 as it now stands,
with things cleaned up) with this split.

-- 
Robert Krawitz <[EMAIL PROTECTED]>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to