Bug#334747: updmap-sys --syncwithtrees
Florent Rougon [EMAIL PROTECTED] wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
Thanks! I haven't tested it yet, but from looking at the source I have
one comment. I think '--enable' and '--disable' can be removed from
$bad_options for updmap-sys, since these are debianized via Frank's
debianze-updmap.
Mmmm... but according to updmap-sys(1):
When used with the options --edit, --setoption, --enable, --disable, or
--syncwithtrees, updmap will first write updmap.cfg(5) and regenerate
the map files only if this file has been changed. In Debian, updmap
has been adapted so that these options do the right thing: change the
configuration snippets in updmap.d instead, call update-updmap(1) to
regenerate updmap.cfg(5) and regenerate the map files afterwards.
Unfortunately, they will be regenerated even if updmap.cfg(5) has not
been changed.
From this text, I would infer that --syncwithtrees is already
debianized. It seems the manpage is in advance!
In fact, but maybe the script can catch up. For --edit, the code in
updmap is simply
edit)
${VISUAL-${EDITOR-vi}} $cnfFile;;
I think we should replace the code with a message that we cannot guess
which file the user wants to edit, and point him to the directory (maybe
with a listing).
With the syncwithtrees option, updmap creates a sed script and then runs
sed with that script over the conffile. I think if sed does not find a
match it silently skips the command, so we could simply run the sed
command iteratively over all files we have found (with the mechanisms
already present), and then reexecute updmap.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Bug#334747: updmap-sys --syncwithtrees
Frank Küster [EMAIL PROTECTED] wrote:
In fact, but maybe the script can catch up. For --edit, the code in
updmap is simply
edit)
${VISUAL-${EDITOR-vi}} $cnfFile;;
I think we should replace the code with a message that we cannot guess
which file the user wants to edit, and point him to the directory (maybe
with a listing).
Agreed.
With the syncwithtrees option, updmap creates a sed script and then runs
sed with that script over the conffile. I think if sed does not find a
match it silently skips the command, so we could simply run the sed
command iteratively over all files we have found (with the mechanisms
already present), and then reexecute updmap.
Hmmm, you are obviously trying your best to have these commands work on
Debian, but is it really a good idea here? For instance, if tetex-extra
is removed-but-not-purged and you use --syncwithtrees, you will
effectively comment out every line of 20tetex-extra.cfg.
Personally, I think I would not care about all that and simply tell them
to edit the files under /etc/texmf/updmap.d/...
--
Florent
Bug#334747: updmap-sys --syncwithtrees
Florent Rougon [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] wrote: With the syncwithtrees option, updmap creates a sed script and then runs sed with that script over the conffile. I think if sed does not find a match it silently skips the command, so we could simply run the sed command iteratively over all files we have found (with the mechanisms already present), and then reexecute updmap. Hmmm, you are obviously trying your best to have these commands work on Debian, but is it really a good idea here? For instance, if tetex-extra is removed-but-not-purged and you use --syncwithtrees, you will effectively comment out every line of 20tetex-extra.cfg. Personally, I think I would not care about all that and simply tell them to edit the files under /etc/texmf/updmap.d/... ACK Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#334747: updmap-sys --syncwithtrees
On Wed, Oct 19, 2005 at 23:05 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: In the case where this started, the user would have been back at 'square one', since updmap-sys would again try to use the still incorrect /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys --syncwithtrees' or 'updmap-sys --edit'. I'm not sure I understand whay you mean. I see two cases: - users who encountered #334658 and did not run 'updmap-sys --syncwithtrees' - for these users, the fix I proposed in #334658 must work (I tested it) - users who encountered #334658 and did run 'updmap-sys --syncwithtrees' - if they blindly follow the same procedure without the rest, they will install lmodern 0.92-9, which will run: update-updmap - generates a correct /var/lib/texmf/web2c/updmap.cfg updmap-sys- uses the bad updmap.cfg under TEXMFMAIN Doesn't work. They have to remove the bad updmap.cfg from TEXMFMAIN first. Is that what you meant? But as far as tetex-bin is concerned, if the bad updmap.cfg is removed before the updmap-sys call in tetex-bin.postinst, things should be all right, no? I didn't take lmodern 0.92-9 into account but only thought about yesterdays situation. A user who encountered #334658 and did run 'updmap-sys --syncwithtrees' will have two updmap.cfg files. One in the right place but with wrong content (still mentions lm.map), one in the wrong place (for Debian) but with lm.map commented out. Now a reconfigure of both tetex-bin and lmodern works, but the LM fonts won't be available. If however, tetex-bin would delete the updmap.cfg in /usr/share/texmf/web2c before running updmap-sys, the updmap.cfg in /var/lib/texmf/web2c would be used. This file still references lm.map, so updmap-sys would fail again, suggesting to use --syncwithtrees or --edit. That's what I meant with 'back at square one'. Now, with the new lmodern in unstable, this can't happen anymore, but your second case is still problematic. Maybe the best place to check for additional updmap.cfg files would be update-updmap. And since one could go around in circles with simply removing additional updmap.cfg files, one might have to inform the user about this, present a diff or something like this ... cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
Ralf Stubner [EMAIL PROTECTED] wrote: I didn't take lmodern 0.92-9 into account but only thought about yesterdays situation. A user who encountered #334658 and did run [...] --edit. That's what I meant with 'back at square one'. OK, thanks for explaining. Now, with the new lmodern in unstable, this can't happen anymore, but your second case is still problematic. Maybe the best place to check for additional updmap.cfg files would be update-updmap. And since one could go around in circles with simply removing additional updmap.cfg files, one might have to inform the user about this, present a diff or something like this ... I fully agree. I may implement that in update-updmap as you suggest, if I don't feel too dizzy (pretty bad night, ugh...). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Thu, Oct 20, 2005 at 11:22 +0200, Florent Rougon wrote: I fully agree. I may implement that in update-updmap as you suggest, That would be great. if I don't feel too dizzy (pretty bad night, ugh...). I don't think we are in a hurry with this. Especially as fmtutil-sys and texconfig-sys might also be affected, it might be necessary to analyze the whole situation more carefully. BTW, I just found out that fmtutil-sys also supports --edit and --enablefmt options (not documented in fmtutil(1) :-(. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
Ralf Stubner [EMAIL PROTECTED] wrote: That would be great. Done. I chose to abort to make sure the user will see the message and not do the same mistake in the future. This is only activated for update-updmap. I don't think we are in a hurry with this. Especially as fmtutil-sys and texconfig-sys might also be affected, it might be necessary to analyze the whole situation more carefully. BTW, I just found out that fmtutil-sys also supports --edit and --enablefmt options (not documented in fmtutil(1) :-(. Well, that's a gift for us. :) -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Thu, Oct 20, 2005 at 19:46 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: That would be great. Done. I chose to abort to make sure the user will see the message and not do the same mistake in the future. Thanks! I haven't tested it yet, but from looking at the source I have one comment. I think '--enable' and '--disable' can be removed from $bad_options for updmap-sys, since these are debianized via Frank's debianze-updmap. BTW, I just found out that fmtutil-sys also supports --edit and --enablefmt options (not documented in fmtutil(1) :-(. Well, that's a gift for us. :) Indeed. :-) cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
Ralf Stubner [EMAIL PROTECTED] wrote: Thanks! I haven't tested it yet, but from looking at the source I have one comment. I think '--enable' and '--disable' can be removed from $bad_options for updmap-sys, since these are debianized via Frank's debianze-updmap. Mmmm... but according to updmap-sys(1): When used with the options --edit, --setoption, --enable, --disable, or --syncwithtrees, updmap will first write updmap.cfg(5) and regenerate the map files only if this file has been changed. In Debian, updmap has been adapted so that these options do the right thing: change the configuration snippets in updmap.d instead, call update-updmap(1) to regenerate updmap.cfg(5) and regenerate the map files afterwards. Unfortunately, they will be regenerated even if updmap.cfg(5) has not been changed. From this text, I would infer that --syncwithtrees is already debianized. It seems the manpage is in advance! Well, looking at the comments in debianize-updmap, only --enable and --disable shouldn't wreak havoc on Debian, at the moment (which is what your message implied). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees (was: Bug#334658: lm.map not found while configuring tetex-bin 3)
[moving this to #334747 where I think it belongs. On Wed, Oct 19, 2005 at 17:12 +0200, Florent Rougon wrote: Florent Rougon [EMAIL PROTECTED] wrote: This should fix everything I am aware of, except maybe the possible mess caused if you followed the 'updmap-sys --syncwithtrees' advice. I still have to check exactly what this does. OK. I have checked now, and the only problem it seems to cause is the creation of /usr/share/texmf/web2c/updmap.cfg, which unfortunately shadows /var/lib/texmf/web2c/updmap.cfg when updmap-sys is run, as pointed out by Ralf (thanks!). It seems to me it would be a good idea to call 'rm -f /usr/share/texmf/web2c/updmap.cfg' maybe in tetex-bin's postinst, somewhere before the updmap-sys run. Otherwise, I fear updmap-sys will keep updating /usr/share/texmf/web2c/updmap.cfg instead of /var/lib/texmf/web2c/updmap.cfg. What do you think? The way I see it right now, both 'updmap-sys --syncwithtrees' and 'updmap-sys --edit' create '/usr/share/texmf/web2c/updmap.cfg'. Especially the latter is quite likely to be used at some point by a local admin who hasn't read the Debian specific docs. I don't think that removing '/usr/share/texmf/web2c/updmap.cfg' during tetex-bin's configuration would be enough. cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
Ralf Stubner [EMAIL PROTECTED] wrote: The way I see it right now, both 'updmap-sys --syncwithtrees' and 'updmap-sys --edit' create '/usr/share/texmf/web2c/updmap.cfg'. Especially the latter is quite likely to be used at some point by a local admin who hasn't read the Debian specific docs. I don't think that removing '/usr/share/texmf/web2c/updmap.cfg' during tetex-bin's configuration would be enough. Right. I'm not claiming it's enough. Simply, it would help people who fell into the trap of these commands, as long as they don't run them again... All I am saying is that this file *has* to be removed on the systems where it was created. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
On Wed, Oct 19, 2005 at 21:23 +0200, Florent Rougon wrote: Ralf Stubner [EMAIL PROTECTED] wrote: The way I see it right now, both 'updmap-sys --syncwithtrees' and 'updmap-sys --edit' create '/usr/share/texmf/web2c/updmap.cfg'. Especially the latter is quite likely to be used at some point by a local admin who hasn't read the Debian specific docs. I don't think that removing '/usr/share/texmf/web2c/updmap.cfg' during tetex-bin's configuration would be enough. Right. I'm not claiming it's enough. Simply, it would help people who fell into the trap of these commands, as long as they don't run them again... In the case where this started, the user would have been back at 'square one', since updmap-sys would again try to use the still incorrect /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys --syncwithtrees' or 'updmap-sys --edit'. All I am saying is that this file *has* to be removed on the systems where it was created. ACK cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334747: updmap-sys --syncwithtrees
Ralf Stubner [EMAIL PROTECTED] wrote: In the case where this started, the user would have been back at 'square one', since updmap-sys would again try to use the still incorrect /var/lib/texmf/web2c/updmap.cfg and again suggest 'updmap-sys --syncwithtrees' or 'updmap-sys --edit'. I'm not sure I understand whay you mean. I see two cases: - users who encountered #334658 and did not run 'updmap-sys --syncwithtrees' - for these users, the fix I proposed in #334658 must work (I tested it) - users who encountered #334658 and did run 'updmap-sys --syncwithtrees' - if they blindly follow the same procedure without the rest, they will install lmodern 0.92-9, which will run: update-updmap - generates a correct /var/lib/texmf/web2c/updmap.cfg updmap-sys- uses the bad updmap.cfg under TEXMFMAIN Doesn't work. They have to remove the bad updmap.cfg from TEXMFMAIN first. Is that what you meant? But as far as tetex-bin is concerned, if the bad updmap.cfg is removed before the updmap-sys call in tetex-bin.postinst, things should be all right, no? [ update-updmap will generate /var/lib/texmf/web2c/updmap.cfg even if updmap.cfg exists under TEXMFMAIN: SYSWIDE_VARD=/var/lib/texmf/web2c DEFAULT_OUTPUTFILE_BASENAME=updmap.cfg SYSWIDE_DEFAULT_OUTPUTFILE=$SYSWIDE_VARD/$DEFAULT_OUTPUTFILE_BASENAME No kpsewhich call here. ] -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
