Bug 455171

I think that it is not a configuration file for the user, it is
for the 'vendor' (packager and upstream). You can do your own
configuration file in /etc/texmf/web2c. Then you may need to 
run mktexlsr in /etc/texmf. Your file will take precedence.

Isn't it a configuration file?  When I read the documentation about how to
install fonts I came to the conclusion it was.  But maybe I'm wrong.

I understand that I could REPLACE the updmap.cfg file by putting a local version
in /etc/texmf.  But what I'm trying to do is to ADD fonts.  I looked in the
updmap script, but as far as I could tell it reads only one configuration file.

In some more detail, what I'm trying to do is to create a couple of RPM
packages, each one adds one or a group of Postscript fonts and makes them known
to TeX.  I do this by having a map-file in the package placed in
/usr/share/texmf/fonts/map/dvips.  The postinstall script then adds a line
referring this map file to updmap.cfg, and runs updmap-sys.  Is there a better
way to create a package adding a font to TeX?

The comment in the updmap.cfg man page about how this is done on Debian appeared
to confirm my understanding.  Apparently, on Debian the updmap.cfg file is
generated from files collected in a updmap.d directory.  In that situation, my
package could drop a file of its own in that directory, and regenerate
updmap.cfg in its postinstall script.  But since it is done that way in Debian,
I assumed there was no way in stock TeX to make updmap read several
configuration files.

Maybe it would be a good idea to follow the Debian solution here.  But until
someone has time to do that, it seems to me that updmap.cfg should be considered
a configuration file.

(In reply to comment #2)
> Isn't it a configuration file?  When I read the documentation about how to
> install fonts I came to the conclusion it was.  But maybe I'm wrong.

It is a configuration file in some sense, but it is a configuration
file under the control of the packager, so not a config file for the user
and not %config.
 
> I understand that I could REPLACE the updmap.cfg file by putting a local version
> in /etc/texmf.  But what I'm trying to do is to ADD fonts.  I looked in the
> updmap script, but as far as I could tell it reads only one configuration file.
>
> In some more detail, what I'm trying to do is to create a couple of RPM
> packages, each one adds one or a group of Postscript fonts and makes them known
> to TeX.  I do this by having a map-file in the package placed in
> /usr/share/texmf/fonts/map/dvips.  The postinstall script then adds a line
> referring this map file to updmap.cfg, and runs updmap-sys.  Is there a better
> way to create a package adding a font to TeX?

Not that I know about.

> The comment in the updmap.cfg man page about how this is done on Debian appeared
> to confirm my understanding.  Apparently, on Debian the updmap.cfg file is
> generated from files collected in a updmap.d directory.  In that situation, my
> package could drop a file of its own in that directory, and regenerate
> updmap.cfg in its postinstall script.  But since it is done that way in Debian,
> I assumed there was no way in stock TeX to make updmap read several
> configuration files.

I think so too.

> Maybe it would be a good idea to follow the Debian solution here.  

Not necessarily the debian solution, but being able to have files
dropped in a directory be used for fmtutil.cnf and updmap.cnf would
be very nice (as in debian).

> But until
> someone has time to do that, it seems to me that updmap.cfg should be considered
> a configuration file.

No. But you are not using it as a config file that should be marked
%config. You are considering it as a config file under the packager
control, so that can have its content change upon package install.
I think that what you want is to have this file marked as:
%verify(not size mtime md5) 
Am I wrong.

(In reply to comment #3)
> It is a configuration file in some sense, but it is a configuration
> file under the control of the packager, so not a config file for the user
> and not %config.

In my particular use case it is modified by the packager of a package different
than the one owning the file.  If you mark it

  %verify(not size mtime md5)

you will shut up "rpm -V".  But %config makes changes to the file persistent
over upgrades, and that is the property I miss here.  Assume I install the
packages a-font, b-font and c-font, each adding a line or two to updmap.cfg. 
And then texlive-texmf is upgraded.  That would remove any changes to
updmap.cfg, and the additional fonts would no longer be available.

> Not necessarily the debian solution, but being able to have files
> dropped in a directory be used for fmtutil.cnf and updmap.cnf would
> be very nice (as in debian).

Yes, I didn't mean to argue for the Debian solution in particular.  I don't know
anything more about it than what I read in the manual page for updmap.cnf

> Am I wrong.

It might as well be me.  But I'm still not sure what to do in my add-on font
packages, that will survive an upgrade of texlive-texmf.

(In reply to comment #4)

> In my particular use case it is modified by the packager of a package different
> than the one owning the file.  If you mark it
> 
>   %verify(not size mtime md5)
> 
> you will shut up "rpm -V".  But %config makes changes to the file persistent
> over upgrades, and that is the property I miss here.  Assume I install the
> packages a-font, b-font and c-font, each adding a line or two to updmap.cfg. 
> And then texlive-texmf is upgraded.  That would remove any changes to
> updmap.cfg, and the additional fonts would no longer be available.

Ok, this is a different issue.

> It might as well be me.  But I'm still not sure what to do in my add-on font
> packages, that will survive an upgrade of texlive-texmf.

The issue here is that installation or update of any package needing to 
modify updmap.cfg should be possible and the changes should be preserved.
This is not achieved by having it %config(noreplace) because texlive-texmf
won't be able to change it anymore.

The only solution I see is to have updmap.cfg content be handled by 
%post scripts. If the file isn't present, it is copied from a knwon 
location (first install of texlive-texmf). And newer entries can be 
added by other packages, or by texlive-texmf updates. This will 
certainly end up being very similar with what debian proposes.

However, it seems to me that these limitations arise from the design of
the updmap.cfg system itself, and so should certainly be handled upstream.

If you have patches to implement something, maybe Jindrich could accept it.

> This is not achieved by having it %config(noreplace) because texlive-texmf
> won't be able to change it anymore.

How is that different from other typical configuration files like, /etc/mail/sendmail.mc or /etc/profile?

Even if I don't add fonts, I may wish to do "updmap-sys --edit --enable..." to make global customizations of my system.  These should also be preserved over an upgrade.

I can agree that it would be good if the Debian system was the upstreams system.  But even if it was, I still think updmap.cfg ought to be marked %config.  (I am not saying arguing for %config(noreplace), plain %config would also help.)

(In reply to comment #6)
> > This is not achieved by having it %config(noreplace) because texlive-texmf
> > won't be able to change it anymore.
> 
> How is that different from other typical configuration files like,
> /etc/mail/sendmail.mc or /etc/profile?

It is not the same use case than /etc/mail/sendmail.mc since 
/etc/mail/sendmail.mc should never need to be modified by the packager.
It is similar with /etc/profile. however /etc/profile is in /etc and in 
/etc file should all be %config. But the equivalent file, here is:

/etc/texmf/web2c/updmap.cf

> Even if I don't add fonts, I may wish to do "updmap-sys --edit --enable..." to
> make global customizations of my system.  These should also be preserved over
> an upgrade.

You should do these changes in /etc/texmf/web2c/updmap.cf
 
> I can agree that it would be good if the Debian system was the upstreams
> system.  But even if it was, I still think updmap.cfg ought to be marked
> %config.  (I am not saying arguing for %config(noreplace), plain %config would
> also help.)

not in /usr/share, but in /etc, sure.

I've been experimenting a little along the lines suggested in comments 5 and others.  In the end, I've come to a pretty simple setup.  I how have a package (I call it "fonts-common") which owns /etc/texmf/web2c/updmap.cfg and /etc/texmf/web2c/updmap.d/00fonts-common.cfg.  It also contains a script called "updfont".  The script concatenates /usr/share/texmf/web2c/updmap.cfg and /etc/texmf/web2c/updmap.d/* to /etc/texmf/web2c/updmap.cfg, and then runs mktexlsr and updmap-sys.  My font packages require this fonts-common, put a config file in /etc/texmf/web2c/updmap.d, and runs the updfont script in %post.

There are a few more details.  For example, my updfont script makes the font available to fontconfig, ghostscript, and the legacy X font system, for example.  But I believe the basic idea as far as TeX is concerned is described above.

Do we want to make a general fedora package along those lines?  If not, I suggest we just close this bugzilla with WONTFIX.  (Or NOTABUG if you prefer.)

I think that it would be nice to do something like you do, but revisit that depending on how it is needed and how it integrates with texlive-2008.

This is also nice if you make fonts available to all applications, this has always be a problem for texlive in fedora.

(In reply to comment #9)
> I think that it would be nice to do something like you do, but revisit that
> depending on how it is needed and how it integrates with texlive-2008.
> 
> This is also nice if you make fonts available to all applications, this has
> always be a problem for texlive in fedora.

Ok I'll see if I can make something more general out of my local scripts.

But on second thoughts, I'll close this case anyway.  A new package would motivate a new bugzilla.

(In reply to comment #9)
> ... but revisit that
> depending on how it is needed and how it integrates with texlive-2008.

After having looked at TeXLive 2008, I see your point.  There are a lot of changes in this regard, with the TeX-specific "package manager" tlmgr.

When regenerating updmap.cfg tlmgr does concatenate a header file with additional Map entries requested by TeX packages.  So it would be possible to make a RPM package contain a TeX package, including a file particular to the package indicating any additional Map lines to add.

We would probably come back to a discussion of what status the updmap.cfg file should have.  If it should be a read-only file in the texlive-texmf package like today, or if it should be a file that is allowed to be changed with %verify(...) exceptions.  Or maybe even %ghost marked, and regenerated in %postinstall by texlive-texmf and all font packages.

In any case, my local scripts briefly described in comment 8 will probably have to be quite different.  So I won't try to make any Fedora package until I see what decisions the TeXLive packager takes when packaging TeXLive 2008.