Menu
▾
▴
omniprint-developer
|
From: Till K. <til...@gm...> - 2001-10-30 21:23:02
|
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 |
|
From: Grant T. <gt...@pi...> - 2001-10-30 22:05:57
|
>>>>> 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". When a user installs a new gimp-print foomatic kit, make kitload automagically uninstall the previous one, and respin all existing configurations against the new data. 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. > 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. Don't go all whacky putting in actual numbers; this will break many things including upgrades. The gimp-print release cycle allows the foomatic generator code there to know if it needs to put -devel on the end or not, so this can be all automagic. Dunno what goes on in OMNI. > 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. > The impact for the database is probably not so high, the server has > plenty of resources That's not the point. *We* don't scale that way, and even if we were to arrange to it wouldn't actually solve a problem. >> Yes, this highlights one thing we need in foomatic: dependency >> checks. PDQ has a scheme for this, whereby you plug in shell code to > 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? Foomatic shouldn't be that clever. It should simply offer a warning at configure time saying "such-and-such driver is not present, setting up anyway". People can either install the driver or pick a different one. Not listing it with -O means that people will never figure out that there is a or a better driver in the world for them. And the -O is used for autodetection as well, remember, so there may be no pruning there. We can get fancy about how to find and install missing drivers later; first things first. -- Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/ Linux Printing Website and HOWTO: http://www.linuxprinting.org/ |
|
From: Till K. <til...@gm...> - 2001-10-30 23:11:01
|
So I will make it this way:
The following driver names will be used:
gimp-print
gimp-print-unstable
omni-unstable
gimp-print will always carry the data of the newest GIMP-Print
(currently 4.2.x). gimp-print-unstable will carry the newest release of
the unstable series (currently 4.3). From Omni there is only a
development version, so there is only an "omni-unstable" driver entry.
Updating will not be done by the usual install script for the rest of
the site. It will be done by a special script, triggered by one of the
following mechanisms:
1. Manually when we get notice of a new release of one of the
drivers. For this we need the info of a new release appearing as
fast as possible, also from the Omni folks.
2. A cron job checks the download sites of Omni and GIMP-Print. When
a new release appears, the update starts.
3. The server account is subscribed to the GIMP-Print and Omni
mailing lists and a script is started through the ~/.forward file.
When a mail announcing a new release arrives, the update is
triggered. This requires the subject line of the announcement
following certain rules, as always being:
ANNOUNCE: gimp-print-4.2.1 released!
The script should do the following:
1. Download new driver release
2. "make" but not "make install" it
3. Remove old option and driver XML files from server.
4. "foomatic-kitload" the new Foomatic data.
5. e-mail the successful execution to Grant and me.
If one of these steps failed the script should not execute any
subsequent steps and mail a log to Grant and me.
This keeps the server always as up-to-date as possible, especially when
the script is triggered by a mailing list announcement or by an hourly
cron job.
For this the authors should cooperate by providing machine-readable
announcement titles, easy recognizable robot-downloadable source
tarballs, foomatic data being built always in the same directory, always
the same steps for building being used.
The authors should also have a decent comment in the driver XML files.
It should give a good, human-readable description of the driver, tell
that the Foomatic data is only for the current release (include version
number here), cross-reference between development and stable release
with links, warn users about possible bugs in unstable and that unstable
can be useful for them when stable does not support their printer.
WDYT about that?
Till
Grant Taylor wrote:
>>>>>>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".
>
> When a user installs a new gimp-print foomatic kit, make kitload
> automagically uninstall the previous one, and respin all existing
> configurations against the new data.
>
> 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.
>
>
>>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.
>
> Don't go all whacky putting in actual numbers; this will break many
> things including upgrades.
>
> The gimp-print release cycle allows the foomatic generator code there
> to know if it needs to put -devel on the end or not, so this can be
> all automagic. Dunno what goes on in OMNI.
>
>
>>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.
>
>
>>The impact for the database is probably not so high, the server has
>>plenty of resources
>>
>
> That's not the point. *We* don't scale that way, and even if we were
> to arrange to it wouldn't actually solve a problem.
>
>
>>>Yes, this highlights one thing we need in foomatic: dependency
>>>checks. PDQ has a scheme for this, whereby you plug in shell code to
>>>
>
>>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?
>>
>
> Foomatic shouldn't be that clever. It should simply offer a warning
> at configure time saying "such-and-such driver is not present, setting
> up anyway". People can either install the driver or pick a different
> one.
>
> Not listing it with -O means that people will never figure out that
> there is a or a better driver in the world for them. And the -O is
> used for autodetection as well, remember, so there may be no pruning
> there.
>
> We can get fancy about how to find and install missing drivers later;
> first things first.
>
|
|
From: Robert L K. <rl...@al...> - 2001-10-31 00:00:19
|
Date: Wed, 31 Oct 2001 01:11:07 +0100
From: Till Kamppeter <til...@gm...>
2. A cron job checks the download sites of Omni and GIMP-Print. When
a new release appears, the update starts.
3. The server account is subscribed to the GIMP-Print and Omni
mailing lists and a script is started through the ~/.forward file.
When a mail announcing a new release arrives, the update is
triggered. This requires the subject line of the announcement
following certain rules, as always being:
ANNOUNCE: gimp-print-4.2.1 released!
If you must, but this seems redundant with (2).
--
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
|
|
From: Till K. <til...@gm...> - 2001-10-31 00:28:16
|
I mean ONE of the three methods, not all at the same time.
Till
Robert L Krawitz wrote:
> Date: Wed, 31 Oct 2001 01:11:07 +0100
> From: Till Kamppeter <til...@gm...>
>
> 2. A cron job checks the download sites of Omni and GIMP-Print. When
> a new release appears, the update starts.
>
> 3. The server account is subscribed to the GIMP-Print and Omni
> mailing lists and a script is started through the ~/.forward file.
> When a mail announcing a new release arrives, the update is
> triggered. This requires the subject line of the announcement
> following certain rules, as always being:
>
> ANNOUNCE: gimp-print-4.2.1 released!
>
> If you must, but this seems redundant with (2).
>
>
|
|
From: Robert L K. <rl...@al...> - 2001-10-31 00:36:30
|
Date: Wed, 31 Oct 2001 02:28:35 +0100 From: Till Kamppeter <til...@gm...> I mean ONE of the three methods, not all at the same time. OK, that makes more sense. -- 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 |
|
From: Robert L K. <rl...@al...> - 2001-10-31 00:00:20
|
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 |
|
From: Grant T. <gt...@pi...> - 2001-10-30 23:26:34
|
>>>>> Till Kamppeter <til...@gm...> writes: > triggered by one of the following mechanisms: Probably the least intrusive thing for driver folks is for you to use one of those web page change polling services to be told about updates. But if Robert or Pete can work up a ping of some sort, that's great. > The authors should also have a decent comment in the driver XML files. Yes, help them out with this; IIRC we pretty much provided the templates in the first place. And of course it's so horribly painful to edit our file format ;( -- Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/ Linux Printing Website and HOWTO: http://www.linuxprinting.org/ |
|
From: Till K. <til...@gm...> - 2001-10-30 23:41:55
|
Grant Taylor wrote: > Probably the least intrusive thing for driver folks is for you to use > one of those web page change polling services to be told about > updates. What are these web page change services? How do they work? Which programs do I need? > But if Robert or Pete can work up a ping of some sort, > that's great. > This means that they give a signal to trigger the script? > >>The authors should also have a decent comment in the driver XML files. >> > > Yes, help them out with this; IIRC we pretty much provided the > templates in the first place. And of course it's so horribly painful > to edit our file format ;( > I could do so and send patches containing the text. They can also send me the text in HTML and then I make an appropriate patch for the driver source tarballs out of that. Till |
|
From: Pete Z. <pz...@us...> - 2001-10-30 23:41:49
|
We will take a look back through these last several notes and see how we can help solidify what we are doing from a driver perspective. Hopefully we can make supporting the different drivers as transparent as possible while we add additional support and features. Thanks, Peter Zannucci IBM Linux Technology Center Open Source Software Development Omni Print Project http://sourceforge.net/projects/omniprint Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us... Grant Taylor <gt...@pi...> on 10/30/2001 05:26:22 PM To: Till Kamppeter <til...@gm...> cc: Robert L Krawitz <rl...@al...>, gim...@so..., Pete Zannucci/Austin/IBM@IBMUS, Omn...@so... Subject: Re: Problem on the stp web page/with Omni >>>>> Till Kamppeter <til...@gm...> writes: > triggered by one of the following mechanisms: Probably the least intrusive thing for driver folks is for you to use one of those web page change polling services to be told about updates. But if Robert or Pete can work up a ping of some sort, that's great. > The authors should also have a decent comment in the driver XML files. Yes, help them out with this; IIRC we pretty much provided the templates in the first place. And of course it's so horribly painful to edit our file format ;( -- Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/ Linux Printing Website and HOWTO: http://www.linuxprinting.org/ |
|
From: Grant T. <gt...@pi...> - 2001-10-31 00:38:42
|
>>>>> Robert L Krawitz <rl...@al...> writes: > 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. Quite. I just want to fix the "gimp-print" driver link that's been broken on my site for maybe a year now. >> 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. I dunno, this still breaks upgrades: if a user of 4.2 installs 4.4 someday, then any like-named option settings should still exist. If we explicitly version the thing, then all the option settings go away. Using "gimp-print" and "gimp-print-devel" allows things to work approximately as they should. -- Grant Taylor - gt...@pi... - http://www.picante.com/~gtaylor/ Linux Printing Website and HOWTO: http://www.linuxprinting.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X