Bug#90664: How's the foomatic package for Debian going?
>>>>> Jeff Licquia <licquia@debian.org> writes:
> 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.
Yes, of course. Manfred has submitted a number of patches, which go
right in.
You're actually welcome (nee encouraged) to put the debian/ stuff into
our CVS. (Till, put your spec in!). We're also hoping to accumulate
any GUI tools in it as well.
> 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.
Yes, that would be good. As is, there's a program to load external
datasets, which just puts a list of filenames into a control file so
they could theoretically be removed/preserved later. But it's a bit
half-assed.
> 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.
Yes, this is a general issue. The original printcap code I wrote went
to great pains to not molest existing printcap data while still
letting you do some operations on it. This is different from, say,
the new redhat thing where the printcap is merely a generated interim
config file. To the extent that it doesn't disturb existing
configuration, foomatic fits with the intent of policy, but not the
letter. OTOH, to the extent that I didn't write all the code and
don't trust even the parts I *did* write, I wouldn't count on it not
scrambling someone someday ;(
--
Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/
Reply to: