Re: xfig can't find fonts
* Steve Langasek [Sat, 10 Jun 2006 21:47:30 -0700]:
> clone 366948 -1
> reassign -1 xfonts-utils 1:1.0.0-4
> retitle -1 update-scale-fonts: fails on empty dirs
> tags -1 = patch
> thanks
(Bounced this to control@, since I can't find the new bug against
xfonts-utils.)
> Hi Dato,
Hey, :)
> On Fri, Jun 09, 2006 at 07:29:42PM +0200, Adeodato Simó wrote:
> > And, as it happens (or at least, as it happened on tests I did on my
> > system), update-fonts-scale fails to update the fonts.alias file in
^^^^^
scale, sorry
> > directories that have become _empty_. See the two attached patches
> > to see how does this happen; either of them (or similar) should be
> > applied to the xfonts-utils package.
> Yes, update-fonts-scale only updates the fonts.scale files, not the
> fonts.alias or fonts.dir files. Looking at your patch, I agree that there's
> a bug in update-fonts-scale, and this does appear to contribute to the
> overall problem we're seeing.
There was a typo avobe, but you got it anyway.
> I think the patch might need a few more tweaks still, though; I'll ponder it
> and commit a fix to the svn repo this weekend.
Nice, thanks. But see comments below about xfonts-utils.postinst.
> > - Steve, despite you talk about horribly broken maintainer scripts in
> > gsfonts-x11, I fail to see anything wrong with them. preinst is the
> > most scary of them, but only acts in versions <= 0.7, and as for
> > postinst and postrm, they just contain the dh_installxfonts snippet.
> Well, yes. The source of the buggy gsfonts-x11 maintainer scripts seems to
> be dh_installxfonts; I've filed a bug report against debhelper now (372686),
> requesting that the postrm snippet *not* check for $1 = upgrade, since this
> issue may come up in other circumstances than just the X11R7 transition.
Two things about this bug report. First, I fail to see (at least for
now) how having the postrm not check for $1 = upgrade would help: when
that code gets executed, the old files are still present in the X11R6
location (or whatever other change in paths), so the tools wouldn't be
able to notice their removal, and update fonts.* accordingly! In the
postinst, on the contrary, the files are already removed, so the tools
can react properly (eventually, once we get the mess sorted out).
Secondly, in the bug report you talk about the need of a new version of
gsfonts-x11, with code in its maintainer scripts to clean by themselves
the old fonts.* files. And again in this mail:
> Anyway, in order to fix this after the fact we need an update to
> gsfonts-x11 so that on upgrade, it takes care of what the old package has
> left behind.
Apologies in advance if I'm being particularly dense on this, but I
can't see what makes gsfonts-x11 sooo special, apart from having got
bitten by a bug in update-fonts-scale. I mean this: gsfonts-x11 leaves
cruft behind in both fonts.scale and fonts.dir in the old dir. For
fonts.scale, the cloned bug against xfonts-utils has to be fixed first,
and then, either gsfonts-x11 gets re-uploaded with a versioned dependency
on xfonts-utils (but then, same should do all the packages shipping
scalable fonts, since who knows which could get upgraded last, without
xfonts-utils being upgraded...), or _maybe_ xfonts-utils can put code in
its postinst to call update-fonts-scale over all directories, iff
upgrading from <= 1:1.0.0-4, in acknowledgement that previous versions
were buggy.
Then, cruft in fonts.dir is left, for which it seems you'd also want for
gsfonts-x11 to handle by itself in its maintainer scripts. But then,
I'll note, and as mentioned in my previous mail:
> > - that gsfonts-x11 leaves stuff in X11R6/fonts.dir is consistent with
> > the changes introduced in #364530: update-fonts-dir only acts in one
> > directory at a time (checked as well with another package, xfonts-jmk
> > maintained by Russ Albery).
_every_ package shipping fonts and which invokes update-fonts-dir leaves
the same cruft behind as gsfonts-x11, so all of them should introduce
the same handling in their maintainer scripts? Maybe what makes
gsfonts-x11 so special is that there have been reports of its cruft
breaking other apps, whilst other font packages have got none, but for
me, all of them behave the same as per dh_installxfonts, so I think the
fix belongs in debhelper, by e.g. invoking update-fonts-dir twice, once
with --x11r7-layout and once without it, or in xfonts-utils, by making
update-fonts-dir act on both directories, like update-fonts-scale.
(That's why I think the bug against gsfonts-x11 is "fixed", and that if
the symptoms remain, it's because another bug, in another package.)
> And even with these fixes to update-fonts-scale (applied also to
> update-fonts-alias), update-fonts-dir doesn't operate on /etc/X11/fonts/*,
> it only operates on the single directory specified. I'm not sure about
> making update-fonts-dir act on both old and new directories; I'd like some
> input from the XSF folks on this first.
> Thinking back, I can't remember now any reason not to make update-fonts-dir
> do this, except perhaps a sense of it being "cleaner" not to.
Okay. As I said, I don't see more options than changing update-fonts-dir,
or changing dh_installxfonts (which doesn't mean there aren't more, of
course).
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Marina Rossell - De què parles, havanera?
Reply to: