On Wed, 2001-11-28 at 12:48, Grant Taylor wrote: > >>>>> Jeff Licquia <[EMAIL PROTECTED]> writes: > > > I'm leaving Thursday on a vacation, and will be back a week from > > Friday. I'll stick the latest foomatic tarball on the laptop and see > > if I get inspired by the beach sand. > > Cool. > > It may be instructive to look at the RPM spec [ Till, please send him > your spec, it doesn't seem to be in CVS ].
Received. Thanks, guys! I've downloaded today's tarball as well. I'm ready to be inspired. :-) > The main headaches are these: > > - Dependencies on a million Perl modules. I think these are mostly > done and in unstable. I didn't see anything that looked bad. > - The /var bit. Last I knew, the library cached computed data in a > parallel cache tree next to the source data. Since that stuff > really belongs in /var, I think we made those locations symlinks > into /var/foomatic/blah rather than adjusting the library to do the > right thing. I take it you'd be interested in a patch that does the right thing? I'll look to see how hard that would be. > - No real version numbering or releases. The bulk of foomatic is a > set of constantly updated data files. There are also external > datasets that people can add to their installation (from > gimp-print, omni, etc). I think Manfred's package was using a > timestamp or something. That's most likely what I'll do - something like "0.20011128-1" for the first version. I will also likely make two packages out of it - one with the code, and one with the local data spool. The idea is that I can pull the data package and use it with older code packages if need be; as long as I keep track of the deps properly, that shouldn't be an issue. Maybe I can even get new data packages installed every so often in stable updates. Now that I think about it, a place for other packages to put their local foomatic dataset would be a good idea, too. If you decide to do release management differently, please give me a heads-up. > Oh - you get 100 bonus points if you can make the various spoolers in > Debian automagically convert configurations when you switch spoolers. > Foomatic has all that logic now, thanks to Till... Cool. The major issue there is "conffile sanctity"; packages are forbidden by policy to mess with registered configuration files except through very tightly-controlled interfaces. (Not all configuration files have to be registered, though; for details - and a good sleep aid - check out the Debian policy manual.) I can tell you for certain that the cupsys maintainer won't mind accomodating. :-) For the other spoolers, I'll have to see how they manage their printer configs. /etc/printcap, in particular, is looking like a potential hot spot for trouble.
