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

Re: texlive2007 and otfinst.py



Hi,

Sorry for answering so late, I had a busy time in the last weeks...

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

> No, that was a thinko.  When patching updmap and fmtutil, we need to
> create these directories for disabling or enabling formats.  But in
> update-fontlang, that doesn't make sense.  Soe for update-fontlang, I
> suggest
>
>     conf_dir=""
>     texmfconfig=$(kpsewhich --expand-path '$TEXMFCONFIG')
>     OLDIFS="$IFS"
>     IFS=:
>     for d in "$texmfconfig"; do
>         if [ -d "$d/$CNFDIR" ]; then
>             conf_dir="$d/$CNFDIR"
>             break
>         fi
>     done
>     IFS="$OLDIFS"
>     # still empty?  Pick one
>     if [ -z "$conf_dir" ]; then
>       echo "No fmt.d directory found in"
>       echo "$texmfconfig"
>       echo "I don't know what you want me to do, exiting."
>       exit 1
>     fi

Please correct me if I'm mistaken, but I think this fixes nothing and
introduces a bug (actually, two), because:

  1) The piece of code you're patching here is in section "Defaults" of
     the script, whose purpose is to determine, well, default values for
     options. As you understood, if [ -z "$conf_dir" ] is true at the
     end of this piece of code, there is no proper default value for the
     configuration directory. BUT the default value can be overridden by
     the --confdir option, which will set conf_dir as the user requested
     it. Therefore, aborting here if [ -z "$conf_dir" ] is true is
     incorrect.

  2) Unless I missed something, I did handle the [ -z "$conf_dir" ] case
     properly, even if the user didn't specify the --confdir option:
     this is done *after* options processing, so that we give the user a
     chance to specify the configuration directory from the command-line:

# In user-specific mode, $conf_dir is required; let's check that.
if [ $syswide_mode = 0 ]; then
    if [ -z "$conf_dir" ]; then
        printf "$progname: "
        cat >&2 <<EOF
unable to determine the configuration directory; you can
specify it with --conf-dir
EOF
        exit 1
    fi

     which is basically the same message as yours, with the addition
     that it hints about --conf-dir to specify the directory.

  3) In the error essage, you wrote "No fmt.d directory", but if I'm not
     mistaken, this could well be "No updmap.d directory" or "No
     language.d directory" depending on $progname. The proper thing to do
     would have been to substitute $CNFDIR to fmt.d here.

While we're at it, I reviewed the whole diff since rev 2052, which
includes the "seen_latex" stuff (special casing for jadetex and xmltex).
About that, I have the following comments:

  1) You have:

include_file()
{

    [...]

    case $file in
      *10texlive-latex-base.cnf)
	seen_latex="true"
	;;
    esac
}

     To be more accurate, I think it should be:

    case $file in
      */10texlive-latex-base.cnf)

    because we don't want this to match e.g.
    '/baz/foobar10texlive-latex-base.cnf' (yes, we are *sure* that there
    is a slash before the file basename, because handle_file is always
    called this way: handle_file "$dir/$lastfile").

  2) Same thing in check_special_jadetex_xmltex(). I suggest to replace:

  case $file in
    *40jadetex.cnf|*40xmltex.cnf)

     with:

  case $file in
    */40jadetex.cnf|*/40xmltex.cnf)

  3) Since we don't use seen_latex out of merge_files(), I would have
     put its initialization to "false" at the beginning of
     merge_files(), for better structuring of the code.

  4) In the case where check_special_jadetex_xmltex() returns false, you
     don't put anything in the final output file (which must be
     fmtutil.cnf unless the user specified something else with
     --output-file). I'd like to include a special snippet to help us
     and our users understand why the snippet wasn't included. I would
     do this with a function similar to do_not_include_file() named,
     e.g., do_not_include_jadetex_or_xmltex_snippet().

If all this is fine with you, I can do the suggested modifications
myself.

Again, sorry for answering so late...

Regards,

-- 
Florent



Reply to: