On Sun, Aug 03, 2008 at 11:40:01PM +0100, Richard Kettlewell wrote: > Daniel Macks wrote: > > On Sun, Aug 03, 2008 at 05:37:50PM +0100, Richard Kettlewell wrote: > >> Martin Costabel wrote: > >>> Richard Kettlewell wrote: > >>>> Obviously this is trivial to work around by setting PKG_CONFIG_PATH, > >>>> but surely this behavior is not as intended? > >>> It is. > >> Why??? > > > > Until a few weeks ago, fink had several different and completely > > incompatible pango libraries available. They obviously can't all be > > installed in the same place, so the one that was the least standard > > (or maybe the one that was newest, I can't remember the history) was > > placed in a subdirectory. You had to explicitly request this > > newer/weirder one (by setting a flag or variable), and packages that > > didn't would continue to behave as before. Well now, many years later, > > we find that this hidden one is the only one that is usable, so the > > other ones are in the process of being scrapped entirely. But again to > > maintain compatibility and consistency for all the packages that are > > expecting it to be buried, gotta keep it there for now. > > That certainly explains the current location, but why not do (the > equivalent of) > ln /sw/lib/pango-ft219/lib/pkgconfig/*.pc /sw/lib/pkgconfig/. > and have the best of both worlds?
It's a good idea (and one we already do for some less-commonly-used packages). Two issues: 1. Need to wait until all traces of the "old" stuff are gone. unstable is done, I think stable is also, but the binary collection still has the old libs in the "normal" place. I know a lot of users still use the binary collection, even though it's old versions (and even try to mix'n'match old-version binaries with newly-built things). So I'd like to wait until we push the new things into bindist. I think drm and maybe some others are working on cleaning up stable enough to do that. 2. Need to avoid breaking the fixes we made for pangocairo. We abolished the old pango1 stuff, but there are still multiple versions (with subdir layout, etc) of freetype itself (and fontconfig, though that looks already buried). Much of the pain of pangocairo wasn't making sure the new paths were used, but making sure they were used *first* in the search lists. We'd need to make sure that if pango1 becomes detected in /sw/lib (for example), configure or Makefile might pass -L/sw/lib before the special /sw/lib/freetype219 and herefore find the "wrong" fontconfig or ft. Our pkgconfig is hacked to prevent this from happening in many cases, but we'd still need to test. Hmm...I wonder if we buried all of the old versions (which are only rarely used) and then brought these new modern ones into the default paths all at once? We first fix the few users of the old stuff, and then scrap all the special hacking of the modern pkgs. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
