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

[Till K. <til...@gm...>]

Grant Taylor wrote:

> Yes, this is likely to be a problem.  We want to have only a few
> popular versions online to prevent a new performance problem ;)
> 
> Till, the thing to do is to blow away the db/ part of the served
> foomatic checkout (ie ~gtaylor/lporg_html/foomatic/db/) each time we
> update, and have a script that does a foomatic-kitload of a gimp or
> two and omni.  Under no circumstances put anything that comes as a kit
> into our cvs.
> 
> We will need version numbers, alas, unless we only provide for
> "stable"; this has an unpleasing property of making configuration
> version specific when it shouldn't be.  I don't like that one bit.
> Perhaps we should use the names gimp-print and gimp-print-devel or
> somesuch.  Then the problem is minimal.
> 


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.

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.

For Omni it should be proceeded in the same way.

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. If the 
authors have special wishes about what to keep and which version's 
Foomatich data to keep and which to drop we can do i appropriately, too. 
I also ask the GIMP-Print/Omni authors to change their Foomatic data 
generation scripts, so that they produce versioned option and driver 
files (as shown above) in all coming releases of their drivers.

The impact for the database is probably not so high, the server has 
plenty of resources, especially where the printer/driver combos are 
computed by C code and not by Perl any more. There is also a lot of free 
disk space. For downloading one could package the CVS (=Foomatic core 
database without GIMP-Print/Omni kits) and the GIMP-Print/Omni kits of 
each currently supported GIMP-Print/Omni version separately. A user 
without need for GIMP-Print/Omni will get the fast small core database, 
a distro takes the core and generates the kits from the actually used 
GIMP-Print and Omni source tarballs. A user who wants to have Foomatic 
data for GIMP-Print/Omni in his local database downloads the core plus 
the desired kit from linuxprinting.org.

The core is already automatically made available every 24 hours from 
CVS. For the kits one could compile the new releases of GIMP-Print and 
Omni on the linuxprinting server and then set up table with the 
locations of the kits, so that our install script installs the core from 
CVS and adds all kits from the table. Obsolete kits will simply be 
removed from the table to not get in when the database is updated. The 
database will be deleted before rebuild to remove obsolete drivers.


> Yes, this highlights one thing we need in foomatic: dependency
> checks.  PDQ has a scheme for this, whereby you plug in shell code to
> check that various executables ro anything else you want are present
> on the system; we'll need something along these lines to help guard
> against gratuitously poor foomatic/gimp-print pairings.
> 

You mean that Foomatic should check which drivers are installed on the 
local machine (GS driver in "gs --help", filter in $PATH, for UPP driver 
upp file available, and version check, shell script for doing these 
checks should be in a field of the driver's DB entry) and 
"foomatic-configure -O" only list ths combos which will work on the 
current system?

    Till