В 18:30 +0800 на 19.08.2009 (ср), Paul Wise написа: > Uhm, perhaps you meant to clone the bug too, since gnustep-back still > needs to switch to using fontconfig?
I'm afraid that I don't understand what you mean. I'll close this bug when we get rid of the defoma dependency. I'll close #454446 when we adopt the orphaned mknfonts.tool, which is a completely independent issue. Why cloning is necessary? > I'm not sure it is appropriate to put generated stuff in /usr/share (FHS > and all), I suggest you use somewhere in /var/ for that. Ah, yes. > That does sound tricky, not sure how to approach that, Well, at least failing to triggerize it won't be a regression. Currently, the .nfont data is regenerated when defoma and/or gnustep-back-common are reconfigured. > other than getting the libart backend to use libfontconfig instead of using > fc-list > in the maintainer scripts. This is not trivial at all, as there are significant differences between the design of the two backends (actually between the 3 -- we don't package the xlib backend currently). Even if it was doable, personally I wouldn't want to diverge from upstream on such fundamental level. > http://wiki.debian.org/OldPkgRemovals Thanks. > IMO you can just check if defoma-app is available and purge if it is, > preventing the need for defoma to stick around in squeeze. This will fail in typical cases when defoma was pulled in as a dependency of gnustep-back-common. Once we drop it, defoma will be removed during the same upgrade run and quite probably won't be available at the time gnustep-back-common's postinst is being run. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
