On Sun, Jun 11, 2006 at 01:40:03PM +0200, Adeodato Simó wrote: > > 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). Uh... hmm. You're right; this is incredibly surprising to me that the postrm script would be called *before* the files have been removed. That's not exactly "post" the "rm" part. So I guess my suggested update to dh_installxfonts was entirely ineffective. :/ It does mean that any package that moves its fonts between directories on upgrade does have to deal with this always in the postinst. Yuck. > 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. I didn't mean to suggest that gsfonts-x11 was special; if there are other font packages with this issue, my thought was that they would need to clean up in the same way. gsfonts-x11 is the one that seems to have been leaving fonts.dir files behind on users' systems with the greatest consistency so far. > 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.) Yes, I've talked with David and he agrees that fixing xfonts-utils so that update-fonts-dir acts on both old and new directories is acceptable. I still think it's rather ugly, but I'm going to go ahead and implement this for the XSF since everything else is ugly too. So, I'll go ahead with the cloning and bug fixing-up since it seems that this *still* hasn't happened on this bug. :) Thanks for the sanity checking! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature