Bug#410158: Cleaning generated pk fonts in maintainer scripts
Hi, Frank Küster [EMAIL PROTECTED] wrote: - clean up the files in each $TEXMFVAR/fonts directory below /home/. I'm not sure this is a good idea, or even allowed by policy I'm pretty sure it is not allowed. Users could well get pissed off if something in their home directory was changed without their consent. -- Florent
Bug#410158: Cleaning generated pk fonts in maintainer scripts (was: Bug#410158: lilypond-data: Wrong Pre-Depends)
I see that the code is both in the (unused) preinst and in lilypond-data.postrm. It's actually not clear to me whether preinst or postrm is the best place to do this. The argument pro preinst is that one could check the old version, and only trigger the removal if we are upgrading and the old version is older than the last change to the fonts. The arguments pro postrm are that you don't need a Pre-Depends, and that file removal makes more sense in a removal script and should also be done upon package removal, not only upgrade (as your postrm script does, correctly). The preinst stuff is there to deal with older buggy versions of the package that did not have a postrm to remove things. But this does not mean it is something we should still care about, or that this is anything like the right way to deal with it. signature.asc Description: This is a digitally signed message part
Bug#410158: Cleaning generated pk fonts in maintainer scripts
[Darn it's late. Why do good parties always have to start after midnight?] From: Florent Rougon [EMAIL PROTECTED] Frank Küster [EMAIL PROTECTED] wrote: - clean up the files in each $TEXMFVAR/fonts directory below /home/. I'm not sure this is a good idea, or even allowed by policy I'm pretty sure it is not allowed. Users could well get pissed off if something in their home directory was changed without their consent. I also have this problem: the old cjk-latex package depended on TFM fonts. When using xdvi or dvips, MakeTeXPK would make the necessary PK fonts. The newest version of latex-cjk depends on Type1 fonts and doesn't need any PK fonts. However, several of these old PK fonts are still in ~/.texmf-var/ (or perhaps even /var/cache/fonts/). This causes the LaTeX process to fail. If I could point you to bug #406701 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406701), where a user had problems processing a CJK LaTeX file because he had such remnants in ~/.texmf-var/fonts/. I've written a note about this, in tempore non suspecto, in the README.Debian in latex-cjk telling users to remove these PK fonts, but I'm afraid few people actually read it. cjk-latex doesn't have a huge user base ATM, so I could probably deal with individual bug reports. But a more structural solution would be preferable. Perhaps writing a debconf warning with big fat red exclamation marks for packages which have to deal with old PK fonts? Best Danai SAE-HAN 韓達耐 -- 題目:《王充道送水仙花五十支》 作者:黃庭堅（１０４５－１１０５） 凌波仙子生塵襪，水上輕盈步微月。 是誰招此斷腸魂，種作寒花寄愁絕。 含香體素欲傾城，山礬是弟梅是兄。 坐對真成被花惱，出門一笑大江橫。
Bug#410158: Cleaning generated pk fonts in maintainer scripts (was: Bug#410158: lilypond-data: Wrong Pre-Depends)
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: On Fri, 2007-02-09 at 07:42 +0100, Frank Küster wrote: No, it's kpsewhich. I'm looking at the script. It does not call mktexlsr; it does call kpsewhich, precisely to figure out the path in which the fonts are located, so that old files, installed by old versions, can be cleaned up. (That's why it's harmless to be missing the file, but I should probably determine after etch whether it needs to be reinstated.) That is actually an interesting issue. It's not been important or even noticed, since the fonts in teTeX or TeXLive that are used as bitmap fonts are mostly not developed any more. This means they do not change and you can use the generated pk bitmap fonts even if they were created on potato. Anyway, you might want to consider to use dh_installtex instead; it safes you the hazzle of following changes in the TeX setup and just does the right thing. It's not in debhelper proper, but in tex-common, but it follows debhelper conventions. I can't see how dh_installtex would help with the old preinst file, which is, btw, right there in the source. :) dh_installtex can replace the code in lilypond-data.postinst, and add the missing mktexlsr call to lilypond-data.postrm[1]. The preinst file I didn't notice, since I was focused on lilypond-data.*. I see that the code is both in the (unused) preinst and in lilypond-data.postrm. It's actually not clear to me whether preinst or postrm is the best place to do this. The argument pro preinst is that one could check the old version, and only trigger the removal if we are upgrading and the old version is older than the last change to the fonts. The arguments pro postrm are that you don't need a Pre-Depends, and that file removal makes more sense in a removal script and should also be done upon package removal, not only upgrade (as your postrm script does, correctly). However, things are not as easy as your script assumes. $ /usr/bin/kpsewhich -expand-var '$VARTEXFONTS' /tmp/texfonts $ ls `/usr/bin/kpsewhich -expand-var '$VARTEXFONTS'` ls: /tmp/texfonts: No such file or directory $ This setting is now only a fallback, and the fonts are stored in per-user directories by default. This was changed because of security considerations (earlier with VARTEXFONTS actually used and in /var, any TeX user could fill up the /var partition). So if we have a package that changes sources for pk fonts, we could - clean up the files in each $TEXMFVAR/fonts directory below /home/. I'm not sure this is a good idea, or even allowed by policy - tell the admin (via debconf messages) that they should notify their users to remove the fonts. Hm. Regards, Frank [1] should I report a separate bug on this? -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
