[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> 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: