(Ghostscript folks, we're starting to talk about splitting up the Gimp-Print project into sub-components.) From: Eric Sharkey <sharkey@xxxxxxxxxxx> 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 <rlk@xxxxxxxxxxxx> 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 lpf@xxxxxxxxxxxx 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
