[Omniprint-developer] Re: Problem on the stp web page/with Omni

[Robert L K. <rl...@al...>]

   Date: Tue, 30 Oct 2001 17:05:40 -0500
   From: Grant Taylor <gt...@pi...>

   >>>>> Till Kamppeter <til...@gm...> writes:

   > I would suggest to always have the newest GIMP-Print/Omni
   > Foomatic data online and some older versions (3 or so). The older
   > versions should be chosen depending on when changes to the
   > Foomatic data of a certain GIMP-Print version occur. Every time
   > when a new GIMP-Print version appears and its Foomatic data is
   > not compatible to the previous version, a new Foomatic data set
   > should be added. Then also the oldest can be removed. The
   > GIMP-Print 4.0 data should conserved for some more tims as
   > "gimp-print-4.0", for GIMP-Print 4.2.0 there should be a
   > "gimp-print-4.2.0", when 4.2.2 will need new Foomatic data there
   > will be a "gimp-print-4.2.2", if there are more than three driver
   > entries for GIMP-Print 4.2.x, the oldest will be removed.

   Ugh.  No, this is the ugliness we want to avoid.  Use "omni" and
   "omni-unstable"; and "gimp-print" and "gimp-print-unstable".  Or
   perhaps "-devel".

Ick.  Not to you, Grant.  I like your approach to it.  It's the
versioning stuff I want to stay away from.

<soapbox>

For drivers like Gimp-print (4.2, at any rate) and Omni, there's *no*
reason for people to download Foomatic kits from linuxprinting.org.
For legacy drivers that are never going to be changed (like most of
the Ghostscript drivers), it's reasonable to do this.  For
current-generation drivers, which support tons of printers with tons
of features, and are largely data-driven (even if Gimp-print currently
compiles in its data, the interfaces are data-driven), static kits are
absolutely the wrong way to go.  The distribution should build its own
foomatic kit.  Peter Zannucci and I discussed this on the Foomatic
development list a while back, and as I recall we were in complete
agreement on this.

The *only* reason to have a snapshot of this in the database is for
the benefit of the printer and driver listings on the
linuxprinting.org web site.

</soapbox>

For Gimp-print, I think having "gimp-print" and "gimp-print-devel"
listings in the database is reasonable.  "gimp-print" gets populated
from the latest stable release (4.2.0, when we release it, and then
each 4.2.x point release as it comes along -- our rules do allow
adding printers and certain kinds of features in stable upgrades).
"gimp-print-devel" gets populated from the latest development release
(not the CVS repository, please).  Omni should make a similar decision
based on their release rules.

   When gimp makes a new release, switch the website to that data.
   Don't try to track all manner of previous releases; that's
   hopeless.  Just flog gimp-print binary distributors into shipping
   the foomatic kits no matter what else they may do.  Perhaps Robert
   would put a two-line "thou shalt configure your gimp-print thusly
   for binary distribution" blurb in his readme.

That's actually a good suggestion.  Now let's just decide what those
rules should be.

   > All options must be versioned, too (ex: option ID:
   > "gimp-print-4.2.0-PageSize", file name:
   > "gimp-print-4.2.0-PageSize.xml", short name: "PageSize", long name:
   > "Page Size"), so that the different GIMP-Print versions do not
   > interfere.

   Yes, but only inasmuch as there is a normal and -unstable driver name.

Perhaps we should use the soname of the library for this purpose?  If
you use shared libraries, you won't be able (without some nasty
LD_LIBRARY_PATH hacking) to have 4.2.0 and 4.2.1 installed
simultaneously, because the library sonames will be the same.

   > This requires from both the authors of Omni and GIMP-Print that
   > they inform Grant and me about every release and which release
   > needs new Foomatic data, so that we can keep linuxprinting.org
   > up-to-date.

   For all releases just do the update exercise regardless; you pretty
   much do this now as a function of making libgimpprint and omni
   rpms.

Right.  Just grab each release as it comes along.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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