Bug#90664: How's the foomatic package for Debian going?
On Wed, 2001-11-28 at 12:48, Grant Taylor wrote:
> >>>>> Jeff Licquia <licquia@debian.org> 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.
Reply to: