Bug 968573

Immediately after installing a new font package, the updmap.cfg file will have both disabling and enabling commands, as in

 #! Map EBGaramond.map
 Map EBGaramond.map

but the relevant entries are *not* created by the execution of

/usr/bin/updmap-sys --syncwithtrees

in the posttrans scriptlet.  

My conjecture is that --syncwithtrees should not be used here. If one
executes updmap-sys immediately after installation without that option, the relevant entries are created in psfonts.map and pdftex.map. I'd guess that a call with syncwithtrees could be used *after* a normal call of updmap-sys.

Another possibility is that it's the --nohash option combined with --syncwithtrees that's problematic.  If texhash isn't executed, the relevant Map file will appear to be unavailable.

My conjecture has been confirmed at texlive.  A call of updmap-sys *without* --syncwithtrees is needed in the posttrans script. (Comment 2 above is spurious because texhash is called earlier in the script.)

I believe the commands

sed -i '/^Map EBGaramond.map/d' /usr/share/texlive/texmf/web2c/updmap.cfg
echo "Map EBGaramond.map" >> /usr/share/texlive/texmf/web2c/updmap.cfg

aren't satisfactory because they result in the map file being both enabled
and disabled.

It seems this bug was introduced as a result of an over-zealous response to an earlier bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=915086

where I suggested only that updmap-sys --syncwithtrees be executed
"when texlive is installed".

Thanks for investigation. So do you think just updmap-sys call without any parameters will suffice?

I think 

sed -i '/^Map EBGaramond.map/d' /usr/share/texlive/texmf/web2c/updmap.cfg
echo "Map EBGaramond.map" >> /usr/share/texlive/texmf/web2c/updmap.cfg
updmap-sys --syncwithtrees

should essentially be replaced by

updmap-sys --syncwithtrees
updmap-sys --enable Map=EBGaramond.map 

and 

sed -i '/^Map EBGaramond.map/d' /usr/share/texlive/texmf/web2c/updmap.cfg

by

updmap-sys --disable EBGaramond.map

But I'm not sure of the consequences of using postinstall vs. posttrans.
I'm guessing you want postinstall to enable the relevant map file without generating psfonts.map etc., and posttrans to do the latter for all newly installed font packages. If so, do 

updmap-sys --enable Map=EBGaramond.map --nomkmap

in postinstall and
 
updmap-sys --syncwithtrees
updmap-sys

in posttrans and similarly for uninstall.

Hi Jindrich, hi all

here some information how things *could* be organized and what needs to be called, although Bob has already explained most of the things.

In principle it is possible to use sed as you do to activate/deactivate the map files, but be aware that updmap now reads *ALL* possible updmap.cfg files. That means, if you use sed to change the status you might change it in one file that is lower down in the hierarchy of updmap.cfg files, thus having no effect.

If you only deal with packaged (rpm) additions to the updmap.cfg file, then the approach you are taking is fine, the only things that is needed afterwards is a call to updmap-sys, without any additional arguments.

In particular, the call to --syncwithtrees is *not* a good idea. It is the brute force method to make sure nothing evil happens, but does not ensure consistency, nor actual functionality. Think about a package trying to activate a map file, but in fact forgetting to ship this map file, or shipping it in the wrong place. Then --syncwithtrees will disable this map file, and nobody will realize it until trying to use the fonts.

So I do *not* recommend using --syncwithttress, but instead making sure that the map snippets that are installed are properly activated.

I don't understand the difference mentioned above between postinstall and posttrans. If this is something similar to the trigger mechanism in Debian's dpkg (deferring the execution of some code), then calling (as suggested) updmap -sys --nomkmap --enable Map foo.map immediately, and deferring the final call to updmap-sys (without arguments) to the end of the installation run, this is possible and makes sense.

Hope that helps, if there are any other questions, let me know.

Norbert

In 

https://bugzilla.redhat.com/show_bug.cgi?id=915086

I reported that, after a fresh installation, upmap.cfg had many map files
enabled for packages that weren't installed. So I suggested that --synwithtrees be used when texlive is installed.  But that might not be the correct solution.

Jindrich:  why are map files for uninstalled packages enabled?

syncwithtrees is practically *never* the right solution!!! It does not activate new map files (impossible), only deactivates those that are listed but not present.

The packaging infrastructure of RedHat should keep track which font packages are installed and recreate the updmap.cfg file new.

In Debian every font package creates a file in dir under /var/lib/ and the actual updmap.cfg file for /usr/share/texmf (and other trees) are recreated a new when a font package is installed.

User/Sysadm adaptions should *NOT* go into the updmap.cfg file in /usr/share/texmf or any other tree but TEXMFSYSCONFIG or TEXMFLOCAL's updmap.cfg

In Debian we have:
# kpsewhich --all updmap.cfg
/usr/local/share/texmf/web2c/updmap.cfg
/usr/share/texmf/web2c/updmap.cfg
/usr/share/texlive/texmf-dist/web2c/updmap.cfg
#

The first one is created by me as sysadmin for my local fonts in TEXMFLOCAL
The second one is recreated on every installation of a font package into /usr/share/texmf
The third one is recreated on every installation/update of a TeX Live package

To those sysadmins can use TEXMFSYSCONFIG = /etc/texmf (or TEXMFLOCAL) to disable maps.

Hope that helps

Norbert

Hi Bob,

(In reply to Bob Tennent from comment #7)
> Jindrich:  why are map files for uninstalled packages enabled?

The map files for uninstalled packages shouldn't be present in the updmap.cfg. If they are, then it is a bug. The sed expressions will add and should remove map references in updmap.cfg if a package shipping it is uninstalled.

Hi Norbert,

(In reply to Norbert Preining from comment #8)
> syncwithtrees is practically *never* the right solution!!! It does not
> activate new map files (impossible), only deactivates those that are listed
> but not present.
> 
> The packaging infrastructure of RedHat should keep track which font packages
> are installed and recreate the updmap.cfg file new.
> 
> In Debian every font package creates a file in dir under /var/lib/ and the
> actual updmap.cfg file for /usr/share/texmf (and other trees) are recreated
> a new when a font package is installed.
> 
> User/Sysadm adaptions should *NOT* go into the updmap.cfg file in
> /usr/share/texmf or any other tree but TEXMFSYSCONFIG or TEXMFLOCAL's
> updmap.cfg
> 
> In Debian we have:
> # kpsewhich --all updmap.cfg
> /usr/local/share/texmf/web2c/updmap.cfg
> /usr/share/texmf/web2c/updmap.cfg
> /usr/share/texlive/texmf-dist/web2c/updmap.cfg
> #
> 
> The first one is created by me as sysadmin for my local fonts in TEXMFLOCAL
> The second one is recreated on every installation of a font package into
> /usr/share/texmf
> The third one is recreated on every installation/update of a TeX Live package
> 
> To those sysadmins can use TEXMFSYSCONFIG = /etc/texmf (or TEXMFLOCAL) to
> disable maps.
> 
> Hope that helps
> 
> Norbert

Thanks for suggestions. Actually the post/posttrans scriptlets only touches /usr/share/texlive/texmf-dist/web2c/updmap.cfg for now. The reason for not using directly updmap-sys --enable was originally a need to not to depend on tetex CTAN package which brought in many additional dependencies. I just checked the tetex package is not that big any more so maybe to convert to use updmap-sys --enable is a way to go now. I will have a look into this.

On a slightly unrelated note, you mention that you recreate the updmap.cfg packages completely when installing a new font package? Doesn't it wipe out references to other maps in updmap.cfg?

Thanks!

Jindrich

P.S. To answer your question - post actions are ran after every single package is installed, posttrans are ran once per transaction after everything is already installed.

I'm confused. 

If syncwithtrees is practically *never* the right solution, why does calling updmap-sys after a fresh partial install of texlive on Fedora list dozens of enabled but non-existent map files in /usr/share/texlive/texmf-dist/web2c/updmap.cfg and insist that I run updmap-sys  --syncwithtrees to disable them, this despite all the --syncwithtrees calls currently in the font package scripts which seem to be ineffective, presumably because they require confirmation?  How else could one enable non-distribution map files?  

Jindrich: why would updmap-sys with enable/disable create more dependencies than updmap-sys by itself?

Hi Jindrich, hi Bob,

(In reply to Jindrich Novy from comment #9)
> The map files for uninstalled packages shouldn't be present in the
> updmap.cfg. If they are, then it is a bug.

Ok, reasonable.


(In reply to Jindrich Novy from comment #10)
> Thanks for suggestions. Actually the post/posttrans scriptlets only touches
> /usr/share/texlive/texmf-dist/web2c/updmap.cfg for now. The reason for not
> using directly updmap-sys --enable was originally a need to not to depend on
> tetex CTAN package which brought in many additional dependencies. I just
> checked the tetex package is not that big any more so maybe to convert to
> use updmap-sys --enable is a way to go now. I will have a look into this.

Well, you could simply install the updmap.pl script, it should work as soon as kpsewhich works.

> On a slightly unrelated note, you mention that you recreate the updmap.cfg
> packages completely when installing a new font package? Doesn't it wipe out
> references to other maps in updmap.cfg?

We only recreate /usr/share/texmf/web2/updmap.cfg and /usr/share/texlive/texmf-dist/web2c/updmap.cfg. 

Since updmap reads *all* .cfg files, sysadmins have to edit /etc/texmf/web2c/updmap.cfg or the one in TEXMFLOCAL.

So yes, if a sysadm edits by hadn /usr/share/texmf/web2c/updmap.cfg, then these changes will be wiped out. But this is to be expected, one cannot edit arbitrary files. Only configuration files, in Debian parlour conffiles, are guaranteed to be preserved. In this case /etc/texmf/web2c/updmap.cfg.

Since /etc/texmf/web2c/updmap.cfg is high in the priority queue, it can be used to override *whatever* there is in /usr/share/texmf/web2c/updmap.cfg or /usr/share/texlive/texmf-dist/web2c/updmap.cfg.

Example: Since I have purchased the mtpro(2) fonts, I don't want the belleek.map be activated. I put into /etc/texmf/web2c/updmap.cfg:
# disable beelek
#! Map belleek.map
Map mathpi.map
Map mt-plus.map
Map mt-yy.map

with the effect that in the final generated files the font definitions from the belleek.map file are not included, but the others.

> P.S. To answer your question - post actions are ran after every single
> package is installed, posttrans are ran once per transaction after
> everything is already installed.

Ok, this is what I supposed, in Debian parlor: postaction and triggers ;-)

(In reply to Bob Tennent from comment #11)
> If syncwithtrees is practically *never* the right solution, why does calling
> updmap-sys after a fresh partial install of texlive on Fedora list dozens of
> enabled but non-existent map files in
> /usr/share/texlive/texmf-dist/web2c/updmap.cfg and insist that I run
> updmap-sys  --syncwithtrees to disable them, 

I don't know.

I *suppose* that the updmap.cfg file that is in our tree is shipped as is. Thus, it contains *all* possible map files in the TeX Live environment. But if the packaging splits that into smaller units, then not all of TeX Live might be installed, but still the full updmap.cfg.

That is the reason why I said it is wrong.

Hint for Jindrich: If it is not done, in fact the tlpdb should be read (there are the perl modules!) and the execute action addMap/addMixedMap/addKanjiMap have to be evaluated! I mentioned this in my talk, specifically this bug, at FOSDEM. The slides are at http://www.preining.info/talks/fosdem13.pdf

All the best

Norbert

texlive-2013-0.1.20130608_r30832.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/texlive-2013-0.1.20130608_r30832.fc19

texlive-2013-0.1.20130608_r30832.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/texlive-2013-0.1.20130608_r30832.fc18

Package texlive-2013-0.1.20130608_r30832.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing texlive-2013-0.1.20130608_r30832.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10849/texlive-2013-0.1.20130608_r30832.fc19
then log in and leave karma (feedback).

(In reply to Fedora Update System from comment #15)
> Package texlive-2013-0.1.20130608_r30832.fc19:
> * should fix your issue,
> * was pushed to the Fedora 19 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing
> texlive-2013-0.1.20130608_r30832.fc19'
> as soon as you are able to.
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2013-10849/texlive-2013-0.1.
> 20130608_r30832.fc19
> then log in and leave karma (feedback).

Please make the fc18 versions available in a repo; I don't have a fc19 system to test the fc19 updates with.

Looking at texlive.spec, I don't think this update will work.  The --syncwithtrees calls won't be effective unless the disablings are confirmed. Then the other calls to updmap-sys won't be effective, no matter how many times you do them (a call with --enable Map normally generates new map files unless --nomkmap is used).  As Norbert has emphasized, --syncwithtrees isn't the right solution to this problem.

 
> Looking at texlive.spec, I don't think this update will work.  The
> --syncwithtrees calls won't be effective unless the disablings are
> confirmed. Then the other calls to updmap-sys won't be effective, no matter
> how many times you do them (a call with --enable Map normally generates new
> map files unless --nomkmap is used).  As Norbert has emphasized,
> --syncwithtrees isn't the right solution to this problem.

Most of this is confirmed (on a fresh install of F19).  Two KanjiMap files
(morisawa.map, otf-cktx.map) are enabled but missing (unless ptex and japanese-otf are installed).  Then calls to updmap-sys will enable Map files in updmap.cfg but won't generate new font-map files. Unless you can script confirmation of the disablings, updmap-sys --syncwithtrees calls will be ineffective.

Suggestions:  

 + delete the references to morisawa.map, otf-cktx.map in updmap.cfg
 + add --nomkmap to the updmap-sys calls in post scripts
 + delete all the --syncwithtrees calls in posttrans scripts
 + verify before release that, after an install or partial install of texlive, updmap-sys actually works!

As suggested by comment 5, the disable option is

  updmap-sys --disable EBGaramond.map
  
not --disable Map=EBGaramond.map as in
texlive-ebgaramond-svn30741.0.15__2013_05_22_-0.1.fc18.noarch.rpm
With Map= , the disable option in updmap-sys
(excuting /usr/share/texlive/texmf-dist/scripts/texlive/updmap.pl)
reverts to ENable in subroutine enable_disable_maps .

After uninstalling texlive-ebgaramond, the run-* files under /var/run/texlive
that should trigger parts of the posttrans script,
which should remove those files, are still present.
That could result from a premature exit but I understand from
http://fedoraproject.org/wiki/Packaging:ScriptletSnippets
that posttrans is not run at all for uninstall.

texlive-2013-0.1.20130608_r30832.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Problems persist.  After a fresh install of texlive-collection-latex, morisawa.map, otf-cktx.map are enabled but missing. This causes updmap-sys to fail.  I'll repeat the suggestions made earlier and apparently ignored:

 + delete the references to morisawa.map, otf-cktx.map in updmap.cfg
 + add --nomkmap to the updmap-sys calls in post scripts
 + delete all the --syncwithtrees calls in posttrans scripts
 + verify before release that, after an install or partial install of texlive,   updmap-sys actually works!

texlive-2013-1.20131014_r31898.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/texlive-2013-1.20131014_r31898.fc20

texlive-2013-1.20131014_r31898.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/texlive-2013-1.20131014_r31898.fc19

Package texlive-2013-1.20131014_r31898.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing texlive-2013-1.20131014_r31898.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19153/texlive-2013-1.20131014_r31898.fc20
then log in and leave karma (feedback).

texlive-2013-2.20131019_r31948.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/texlive-2013-2.20131019_r31948.fc18

texlive-2013-3.20131021_r31961.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.