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:[EMAIL PROTECTED] +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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]