Frank Küster <frank@debian.org> wrote:
> In theory I agree (although updmap.cfg is not a confile). In practice,
> tetex's maintainer scripts bluntly refuse to leave things in
> configuration files if they know that this will cause the script to fail
> - e.g. we are commenting ukhyphen.tex in language.dat. I would be
> willing to look at this from a similar viewpoint. On the other hand, of
> course it is a difference whether fiddling with user configuration is
> done in cases of emergency, or as part of a newly established policy.
>
> Well, I never really meant to advocate this scheme. I just wanted to
> explain how it could work, technically
OK...
>> [ Open for discussion: whether to run try_to_update_fontmaps() on purge,
>> i.e. update-updmap, mktexlsr and updmap. This takes a while, and is
>> usually useless because purge is usually called after remove, which
>> already did that. It is not useless if the user removed the lmodern,
>> broke his config (map files, or whatnot) and then purges lmodern.
>> Running try_to_update_fontmaps() might fix his broken config at this
>> point but I am not sure it is worth annoying all other users just for
>> that, we should rarely happen and is a user error anyway.
>
> and dpkg-reconfigure tetex-bin (or any TeX-font-related package) will do
> the same, won't it?
Yes.
>> #
>> ### /etc/texmf/updmap.d/10lmodern.cfg not included because the
>> ### corresponding package seems to be removed.
>> #
>
> Hm, well, this is not nice. But it's just an aesthetic flaw, and even
> might have good side effects when it comes to debugging ("Can you
> remember whether $bla was installed prior to your dist-upgrade?").
Right. BTW, we *could* solve the aesthetic problem by running
update-updmap on purge (this one is very fast, of course), but it
strikes me as looking for problems to run update-updmap not followed by
updmap. If the system is in a clean state, it should have no effect, but
there might be confusing cases...
> Does that mean that you are willing to continue maintaining lmodern even
> after teTeX 3.0 is out? This would be good news, especially because
> lmodern will change much faster than tetex.
Yes. I even received a mail from upstream last week, answering my old
questions of... February; they resumed their work on the fonts. Good
news!
> There's also a script, dpkg-repack or similar - it has been discussed on
> -devel last week or the week before. By the way, if you have compiled
> tetex-bin once and don't call the clean target, it is quite easy to make
> changes to the packaging. In the 2.9 packages, it should be sufficient
> to remove build-stamp (so that it compiles tetex-xwarn if necessary),
> and you can even exchange the complete debian/ directory that way.
Thanks. Will be useful next time.
>> tetex-base still contains /usr/share/texmf/dvips/config. I suppose it is
>> done on purpose for backward compatibility.
>>
>> % ls -l /usr/share/texmf/dvips/config
>> lrwxrwxrwx 1 root root 17 2004-12-21 02:10 /usr/share/texmf/dvips/config -> /etc/texmf//dvips
>
> Yes, I was thinking of other font packages not moving their files fast
> enough. But perhaps it would be the better approach to remove that link
> and notify the maintainers - both by a mail and by the bug reports they
> get.
I don't mind much which way is chosen. It only causes a warning, after
all...
>> but does not fail, though. Also, please note the double "/" in the
>> link's target.
>
> Does that make any difference? It seemed to me not, so I didn't bother
> to remove it.
It doesn't seem to. Just a bit weird to look at.
>> I used debian-fontmap-cfg to avoir potential clashes with future
>> upstream directories... This is of course open to discussion... We could
>> have a whole debian hierarchy under /var/lib/tetex but that would make
>> things a bit deep.
>
> /var/lib/tetex/debian-fontmap-cfg looks good to me.
I said that because currently, I believe the two other items I have in
/var/lib/tetex, i.e., a README file and a tetex-extra directory, are
Debian additions, so they should theoretically have a debian prefix as
well to avoir potential clashes with future upstream additions... Now,
maybe you would prefer having all the items non-prefixed, sitting in a
/var/lib/tetex/debian directory...
[ I know that at least the README will change and perhaps even
disappear, but that doesn't mean we won't ever need to put any other
debian-specific stuff than debian-fontmap-cfg in /var/lib/tetex... ]
--
Florent