The question is whether this could be used as an opportunity to scrap Fink's freetype2 packages.
I believe it is. We should dump freetype2 altogether, but we can't just "provide" freetype2 from the xfree86 packages. Currently, just to get people testing the panther tree, I've got a dummy freetype package that makes the shlib but not the dev stuff, so that the panther freetype-config and such gets found instead.
In the long run, I think we should make a provides: freetype2-xfree86 and modify freetype-using pakcages to depend on that instead.
It seems more reasonable to me to modify the xfree86-4.3.0 and system-xfree86-43 packages so that they Provide and Replace freetype2 and also Conflict with freetype2, rather than patch every package that depends on freetype2. This could actually be done even now in 10.2-gcc3.3, and it seems to me the only possible solution that does not require changing package descriptions between 10.2-gcc3.3 and 10.3.
The compatibility versions are wildly different, so we can't just make symlinks to make things happy, everything has to be rebuilt. Binaries built against fink's libfreetype won't work against X's.
So unless we updated every package with versioned depends or something, we couldn't guarantee things would be rebuilt anyways. Either way we end up having to edit everything that uses freetype, we might as well figure out the best way to do it for the long term.
-- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE We put a lot of thought into our defaults. We like them. If we didn't, we would have made something else be the default. So keep your cotton-pickin' hands off our defaults. Don't touch. Consider them mandatory. "Mandatory defaults" has a nice ring to it.
pgp00000.pgp
Description: PGP signature
