On Wed, 2009-08-19 at 14:48 +0300, Yavor Doganov wrote: > 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 blind, I didn't see that you were modifying a different bug. > > 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. Well, the idea would be to get upstream to make the change. > > 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. Hmmm. Perhaps you could run defoma-app when it is available or simulate it when it is not available? Also, when defoma itself is removed, it will call purge with your script. -- bye, pabs http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
