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

Bug#334613: tetex-bin: same problem still exists



Kenward Vaughan <kay_jay@earthlink.net> wrote:

> On Tue, Nov 08, 2005 at 09:48:34AM +0100, Frank Küster wrote:
>> Kenward Vaughan <kay_jay@earthlink.net> wrote:
>> 
>> > I'm attaching the output of this and the others asked by Frank.  I did
>> > include a listing of /etc/texmf as well (1st run wasn't recursive).
>> 
>> > Script started on Mon 07 Nov 2005 04:05:16 PM PST
>> > 
>> > 04:05:16
>> > daddy:~# ls -l /etc/texmf/updmap.d/
>> > total 11
>> > -rw-------  1 root root 2789 2005-11-06 07:52 00updmap.cfg
>> > -rw-r--r--  1 root root 2787 2005-11-06 07:52 00updmap.cfg.dpkg-dist
>> > -rw-r--r--  1 root root 2623 2005-10-19 07:10 10tetex-base.cfg
>> > -rw-r--r--  1 root root 1314 2005-10-19 07:11 20tetex-extra.cfg.dpkg-new
>> 
>> This shows that tetex-extra is not configured yet (of course, since
>> configuring tetex-bin fails, and -extra depends on -bin), and that you
>> still use the old 00updmap.cfg, and did not yet merge the changes which
>> came with 00updmap.cfg.dpkg-dist.  This shouldn't create a problem, but
>> it's recommended that you once take the time and merge the changes, and
>> remove the dpkg-dist file afterwards.
>
>
> I don't know how to do do this merging of the old and new.  What steps
> would I take to even figure out the differences?  Is it 00updmap.cfg
> that I need to examine, or are there others?

10tetex-base.cfg is okay, and 20tetex-extra.cfg.dpkg-new shouldn't be
touched, dpkg will rename it once it comes to try to configure
tetex-extra.  So this is all about 00updmap.cfg and it's *.dpkg-dist
version.  

Just run a diff, e.g.

diff -u /etc/texmf/updmap.d/00updmap.cfg /etc/texmf/updmap.d/00updmap.cfg.dpkg-dist

This will show (with a - in front) what is in 00updmap.cfg but missing
in *.dpkg-dist, and with a + in front what is new in *.dpkg-dist.  Most
probably the output will look like this:

-dvipdfmDownloadBase14 false
+dvipdfmDownloadBase14 true

(or with some comment lines affected, too).  This means that previously
the setting was false, now it's true by default.  The reason for the
change is that now Adobe recommends to embed even the Base14 PostScript
fonts in PDF files, and here "Download" means "get them and put them
into the file".

If it turns out that you don't have any important hand-made changes in
00updmap.cfg, you can simply discard the old version and move
00updmap.cfg.dpkg-dist to 00updmap.cfg.

>>  grep TEXFONTMAPS /etc/texmf/texmf.d/*
>>  grep TEXFONTMAPS /etc/texmf/texmf.cnf
>
> Here ...
>
> 08:49:38
> daddy:~#  grep TEXFONTMAPS /etc/texmf/texmf.d/*
> /etc/texmf/texmf.d/55Fonts.cnf:% TEXFONTMAPS = .;$TEXMF/{fonts/map,}/{$progname,pdftex,dvips,}//
> /etc/texmf/texmf.d/55Fonts.cnf:TEXFONTMAPS = .;$TEXMF/{fonts/map,}/{$progname,pdftex,dvips,}//;$TEXMF/dvips//
>
> 08:49:40
> daddy:~#  grep TEXFONTMAPS /etc/texmf/texmf.cnf
> TEXFONTMAPS = .;$TEXMF/fontname

Let me explain:  Although texmf.cnf is in /etc/ (because we assume that
many people would edit it even if it was in /var/lib/texmf, and be
surprised their changes get overwritten), it is a generated file: It is
generated from the pieces in texmf.d/*.cnf.  In order to *not* overwrite
local changes in texmf.cnf, it is regenerated using ucf, which provides
a dpkg-like interface: If texmf.cnf has been manually edited, but now -
since one of the files in texmf.d has changed - the autogeneration would
produce something else than it would have produced previously, the local
admin (you) is asked about the changes, like dpkg does.

It seems you have refused to accept the changes, and therefore still got
the old setting in texmf.cnf.  To fix it, you could just take over this
one line from 55Fonts.cnf, however, since you don't seem to be familiar
with conffile merging, I would suggest to do it differently, because it
will be a bit harder now, but save you a lot of trouble in the future:

1. Save a copy of texmf.cnf somewhere

2. Edit 55Fonts.cnf, and introduce some unimportant change - e.g. just
   add a comment line "# comment to help merging changes" (and remember
   what you changed).

3. Run (as root) update-texmf, and this time accept the new
   "maintainer's version". 

4. Now run

diff -u /your/copy/of/texmf.cnf-from-step-1 /etc/texmf/texmf.cnf > texmf.diff

   and examine the file texmf.diff.  For each of the changes indicated,
   you can (of course) decide that you don't care to loose it.  Many of
   the differences are probably not *your* local changes, but simply new
   settings for teTeX-3.0.  But if you want to keep a change, find the
   file in /etc/texmf/texmf.d/ where the setting is made, and change
   that file so that it also contains what your copy of texmf.cnf has.
   If you're unsure whether a change is still needed, just ask us.

5. Run update-texmf again.  This time, if you repeat the diff command,
   the changes should only be the updates for teTeX-3.0, and no changes
   you made for local installed stuff.

6. Remove the comment you added in step 2, and run update-texmf again.


Now in the future, *never* edit texmf.cnf again, but instead just edit
the files in texmf.d.  You will (of course) still be asked by dpkg if
there's a change coming with an update, but now you see a much smaller
difference listing.

>> This is also a candidate for a forcible introduction of the change, as
>> we did previously with TEXMFSYSVAR.

This is something we maintainers should really consider.

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer




Reply to: