> "James R. Van Zandt" <[EMAIL PROTECTED]> wrote:
>
> > 2) Change the default to suit 99% of the cases, and handle the buildds
> > some other way. E.g. isn't there a way to point debconf to a database
> > of answers? I thought there was a mechanism like that, specifically
> > designed for automated installations.
>
> Unfortunately that's not feasible. There's no canonical way to set up a
> buildd, and we cannot require buildd admins, testers etc. to preseed
> their debconf database just because this particular package needs it.
Okay, then I'd say you should mention buildds in the long description.
> > 3) Explain what it means for debconf to manage the permissions.
> > Something like:
> >
> > If you do not accept, then any fonts not in the cache will be
> > generated on the fly for every document. This is the default.
>
> Unfortunately that's not true: Font generation will fail if you don't
> have write permissions.
You mean that if a document requires some font/size/resolution
combination that isn't in the cache, formatting will fail entirely?
That surprises me - I always had mf run automatically to generate the
font. If formatting will really fail, you should definitely document
that in the long description.
> > If you accept, then fonts generated by users in one group will be
> > cached. This saves processing time, costs some disk space, and
> > might compromise security (those users would have write permissions
> > for the font cache). This choice is recommended if you trust some
> > TeX users. You have to manually add those users to the chosen
> > group!
> >
> > Note that this way, you don't really have to mention the buildds.
> > Just invoke security.
>
> Personally, I don't think this is much clearer. It also doesn't explain
> why the built-in default is different from what is recommended,
> especially since a buildd is one of the best situations with respect to
> trusting one's users.
Okay, then mention buildds in the description.
> > BTW I seem to remember a mechanism to clear out
> > rarely-used fonts from the cache. You might mention that, or point to
> > the relevant documentation.
>
> Hm, I don't remember such a mechanism. Any of the others?
I admit it's been a while since I checked into this, and I don't see
anything of the sort now. It would be a cron job (say, a script in
/etc/cron.monthly) that deleted any cached font that had not been read
in a long time, then rebuilt the index as needed. But disks are a lot
bigger and cheaper now, so I guess it's no longer necessary.
- Jim Van Zandt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
