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

Re: CVS frank tetex-base: complete the renaming by removing old named files (now 10tetex-base.cfg)



Frank Küster <frank@debian.org> wrote:

> The parts that really map font names to files, yes.  The first part with
> the options for dvips and friends is still called 00updmap.cfg (but see
> below). 

OK.

> Yes, the 00updmap.cfg part is now in tex-common.  I'm unsure about two
> things:
>
> - it might be better from a practical point of view to change the name
>   from 00updmap.cfg to something else.

You mean, give it a name that sounds close to tex-common?

>                                         On the other hand, the file is
>   already under ucf control, and we'll have to do some clever parsing of
>   the old file, anyway.

I wouldn't mind a renaming of the file but I don't find the current name
too bad. After all, it contains the base of an updmap.cfg file. So, I am
not sure it is not worth the trouble of renaming it.

> - I'm unsure what the sanity check should check for.  If only tex-common
>   is installed, update-updmap currently runs without an error, and
>   produces an updmap.cfg without any font mappings.  However, we cannot
>   simply check for 10tetex-base.cfg, because 10texlive.cfg (or however
>   it will be called) must work, too.  And if somebody removes both files
>   and replaces them with their own version (with a different name), why
>   not let them do this?

It would say that an updmap.cfg without the dvipsPreferOutline & friends
settings (those in 00updmap.cfg) is broken. Therefore, I see no use of
getting rid of this file, nor renaming it (if you keep the contents, why
would you use a non-standard name?...) and I am not sure we should think
hard about what to do in case it isn't there anymore.

If the check fails, it either means that the installation is broken, or
that I presumed wrongly that there is no use of renaming or deleting
00updmap.cfg (or that the user wants to play...). In the first case, the
error message will probably help the user (or us if a bug report is
filed) to debug the problem; in the latter case, we'll get a bug report
and if the reason is convincing, we can remove the check.

The check was there before I touched update-updmap. It is nothing
essential and I have no problem removing it, but currently, it looks
more useful than harmul to me, therfore I didn't remove it. But I might
be wrong. :)

Regards,

-- 
Florent



Reply to: