Re: Debian adaptations for "updmap --enable" and "updmap --diable"
Hi Frank!
On Mon, 22 Aug 2005, Frank Küster wrote:
> It seems to me that this is also an issue for the texlive packages.
> What about moving the script snippet to tex-common? teTeX and texlive
> would then just patch updmap to source and use it.
Good idea. But see below ...
> What do you think about that, Norbert? And if you agree, I'd like to
> hear your opinion about the approach if --enable is used and the script
> finds a commented line for the respective Map in more than one file in
> updmap.d. Should we stop with an error in any case, or do you think
> that using a scheme similar to that I proposed in the file
> http://svn.debian.org/wsvn/pkg-tetex/tetex-bin/trunk/debian/debianize-updmap?op=file&rev=0&sc=0
> would do?
This scheme looks reasonable, but, as I read all this, it seemed to me
all a bit complicated.
Thus, after some glasses of vine, yesterday night, I came up with the
following idea, which may have occurred to others. If yes, please tell
me to shut up if this was already discussed prior to my appearance here.
Forget about update-updmap! There is already a way to activate and
deactivate font maps, --enable/--disable etc. Why not use this.
I propose the following: We know about the map files installed in our
packages, so we call --enableMap when we install them.
In fact there are the following possible options:
a Map file is enabled
a Map file is disabled by root
a Map file is deinstalled from the packaging system and the item disabled
(we leave out user stuff for now, since as soon as a user calls updmap
he got's his own updmap.cfg file in ~/.texmf-config and the system will
not care for this anymore. When the packaging system deinstall some map
files, the user updmap.cfg will not get updated. THis is ok, since it is
the same now)
these three stati have to be recorded in the updmap.cfg file:
enabled:
Map foobar.map
disabled by root:
#! Map foobar.map
deinstalled by the packaging system
#!debian! Map foobar.map
Now for the possible state transitions (sorry, to much logic in my mind)
Variant 1.
dpkg installs -> --enableSysMap
Map foobar.map
dpkg removes -> --disableSysMap
#!debian! Map foobar.map
dpkg installs -> --eneableSysMap
Map foobar.map
Variant 2.
dpkg installs -> --enableSysMap
Map foobar.map
root disables -> --disableMap
#! Map foobar.map
dpkg removes -> --disableSysMap
#! Map foobar.map (NO !debian!)
dpkg installs -> --enableSysMap
#! Map foobar.map (still not, because root disabled)
root enables -> --enableMap
Map foobar.map
dpkg removes -> --disableSysMap
#!debian! foobar.map
What happens if root installs his own map file in lets say
/usr/local/...../baz.map
Variant 3.
root enables -> --enableMap
Map baz.map
root disables -> --disableMap
#! Map baz.map
The only problem I can think of ATM is the following: What happens if
root installs a .map file *WITH THE SAME NAME* as a map file managed by
dpkg?!
Variant 2.1 (a variant of the variant)
root enables -> --enableMap
Map baz.map (baz.map in /usr/local)
dpkg installs -> --enableSysMap
Map baz.map (no we have twp baz.map, local and sys)
dpkg removes -> --disableSysMap
#!debian! Map baz.map
Bummer. This would create problems. Maybe we could check for kpsewhich
baz.map contains "local/share/texmf" and if yes, do not disable it?
But if we could solve this (or ignore this) we would have a simple
solution which is in coherence with the documentation on the web, does
not introduce new commands to administer the system, etc etc etc.
Please tell me what you think, also if you think I had too much vine
yesterday, which in fact is true ;-)
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining AT logic DOT at> Università di Siena
sip:preining@at43.tuwien.ac.at +43 (0) 59966-690018
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BALDOCK
The sharp prong on the top of a tree stump where the tree has snapped
off before being completely sawn through.
--- Douglas Adams, The Meaning of Liff
Reply to: