Re: Policy, updmap --enable and updmap.cfg in /etc or /var
Frank Küster <frank@debian.org> wrote:
> I remember older comments you made. Do you think you can post a short
> "executive summary", so that we can include it into the policy - other
> packages should do it the same way, I think. Or should we offer a
> "tetexpackage-remove_but_not_purge-preserve-map" script to tetex-related
> packages?
I'll try to followup on this next week-end. For the moment, I'll explain
the general ideas. Basically, I see no *very* simple and still really
good solution to our problem:
Without update-updmap
~~~~~~~~~~~~~~~~~~~~~
If we only have updmap.cfg and not update-updmap, the difficult thing
is to have font packages activate and deactivate their maps without
interfering with the customizations made by the admin; one way to do
that is for the maintainer scripts to comment out the lines with a
special style (e.g., #!) and to teach the admin that if he wants his
commenting of a line to be preserved, he has to comment it out with a
different style. I don't like this approach much.
With update-updmap
~~~~~~~~~~~~~~~~~~
The other approach, with update-updmap, looks simpler; at least, it is
simpler and cleaner for the admin. So, we have for every font package
a .cfg file that says "Map foo.map" (or "MixedMap foo.map") for every
map file provided by the package. The idea is that the admin can edit
this file at will and his settings must be preserved.
The first idea that comes when implementing such a scheme, which is
the one written in one of tetex's README files, is to make the .cfg
files conffiles, but this is not correct because the files have to be
renamed or deleted (before calling update-updmap) when the package is
removed so that the "Map foo.map" lines that they contain don't end up
in updmap.cfg when the package is not installed anymore.
So, the approach I took for lmodern is to create a state directory
named /var/lib/lmodern[1] in preinst to store the admin settings when
the package is removed but not purged.
At first installation (or first installation since the package was
last purged), I create the default .cfg file, i.e.
/etc/texmf/updmap.d/10lmodern.cfg. Then, I won't modify it[2]. The
admin can modify it at will, everything will be preserved.
When the package is removed (not purged), I check whether the file is
still there: if yes, I move it to the state directory,
/var/lib/lmodern. If no, I create an empty
/var/lib/lmodern/admin-wants-no-lmodern.cfg to store the fact that the
admin has deleted the .cfg file from /etc/texmf/updmap.d. In both
cases, the .cfg file is not in /etc/texmf/updmap.d anymore, so
update-updmap won't put (Mixed)Map lines for inexistent fonts in
updmap.cfg.
When the package is reinstalled, if /var/lib/lmodern/10lmodern.cfg is
here, it means the admin had not deleted the file under
/etc/texmf/updmap.d, so we move it back there so that update-updmap
adds the Map lines to updmap.cfg the next time it is run (i.e., just
after that, in the postinst). Otherwise, we simply remove
/var/lib/lmodern/admin-wants-no-lmodern.cfg; again in this case, the
user configuration, that is, having the .cfg file under
/etc/texmf/updmap.d deleted, has been preserved.
Of course, when the package is purged, everything is removed: the .cfg
file under /etc/texmf/updmap.d, /var/lib/lmodern and the rest of the
package (simply managed by dpkg).
This is the general idea behind the way I decided to manage this .cfg
file. There are a few more details for dpkg error unwind procedures,
but really not many. In fact, the code is short and "simple", it is
just that producing it in the first place involves a bit of thinking
because you have to keep in your mind about all the possible ways the
maintainer scripts can be called and all the situations your package
can be in, and you have to preserve the idempotency of the maintainer
scripts to be in accordance with the Debian Policy if you want to do
things right. Therefore, most of the "code" in lmodern's maintainer
scripts is made of comments to explain why such line is here and why
such order has to be preserved for the various things accomplished
there.
Of course, if we are to adopt this strategy for all packages that
install fonts, we should use something like
/var/lib/tetex/map-state/$package instead of cluttering /var/lib with
dozens of directories similar to /var/lib/lmodern.
> In any case, all this would be a lot of work, while on the other hand we
> have this simple mechanism with configuration files and update-updmap.
For the time being, the update-updmap solution is the less ugly I can
see that is relatively easily manageable in a policy-compliant way.
[1] /var/state is not FHS compliant, IIRC; I looked at the FHS when I
chose the name, so it should be the proper location.
[2] Well, as I said the other day, in my long term plans, there is the
possibility of using ucf or something to have new defaults merged
in.
--
Florent
Reply to: