On Dec 7, 2007, at 6:44 PM, Jeremy Huddleston wrote:

I don't see why fink binaries won't work right. They should work fine since we symlink /usr/X11R6 to /usr/X11... the problem is in compiling them, right? So compile them on Tiger for now and distribute them as they'll work on Leopard... then as the packages get updated to use pkg-config instead of grep-hacks, things should start to work right on Leopard.

That is infeasible. My impression is that most Fink users (well, at least me) compile from source, because the pre-built binaries available are sometimes rather out of date, or simply nonexistent. I don't have the inclination or the disk space to maintain a Tiger install just to build Fink...

Sorry, I was under the impression it was mainly compile-from- source. I'm glad to see that's not the case.

Fink does both compile-from-source and download-and-install-binaries. Unfortunately, building the binaries is very time consuming and is only done occasionally.

Note: I don't use Fink, so I don't have a fine understanding of their build process.

Well, maybe you should start, because a rather large fraction of the X11 users on the Mac will likely rely on Fink working nicely with X11 changes you make. :-

Yes, I'm sure they will. Personally, I use MacPorts instead of fink. So far, I've noticed a few problems where it pulls in a macports package for a library instead of using the one in /usr/X11 (which is the case regardless of which version of Leopard X11 is installed), and if MacPorts devs don't get them fixed in a few weeks, I'll probably devote some cycles to fixing them up...

Fink is very strict about dependencies and ensuring that packages always build the same on every system. This is necessary for binary packages to work since if a dependency was present on the build machine but not on the user's machine, well, that would be bad. :)

The package manager generates a number of virtual packages that represent things provided by the system to support the dependency system. It also needs to provide version information for those packages. Fink has always provided virtual packages for X11 called system-xfree86-dev and system-xfree86-shlibs which had version 4.4 on Tiger and 7.2 on Leopard. Now they went to 1.3 and currently 0.0, since fink can no longer figure out the version. Now there is currently only one package that explictly depends on system-xfree86- shlibs >=7.2 and that can easily be changed to an unversioned dependency since it's a Leopard-only package anyway. The big problem is that the package manager itself is failing since it can't figure out any version information so it thinks the system is corrupted.

I agree that depending on individual X11 components is probably the right way to go, but the problem is that hundreds of packages in Fink currently depend on system-xfree86-* and changing that would require forcing users to rebuild every package that uses X11 since the dependency information is part of the package. Users will find this...annoying.

Honestly, this problem comes from years of fink having to use ugly grep hacks to figure out version numbers for X11, and there is finally a *real* way for them to check it now. It's sad that they did not get this working right during the Leopard beta, but I'm confident that it will be working soon. As someone else mentioned, most other *nixes went through this hell a few years ago, and it's finally OSX's turn to bite the bullet. This means people relying on X11 support for mission critical needs will need to stick with Tiger or use Tiger's X11 on Leopard for the near future. In the end, however, this will be much more smoother.

Well, this was never an issue with the Leopard seeds since the version checking code still worked. :) And, in fact, still works on the Leopard GM X11.

I'm not a core Fink dev, just a package maintainer, but my suggestion would be to create a new virtual package, maybe xorg-server, and set its version from xorg-server.pc. We wouldn't want to make pkg-config a core dependency, but parsing the version from the .pc file is easy. Then if that package exists, assume that we're using xorg 7.2 and set system-xfree86-* to version 7.2. That way existing packages will continue to work and new packages can migrate to the new virtual package(s). I think I'll suggest that and cross-post this to fink-devel.

In the mean time, I'm volunteering my time to help get this working as quick as possible.

--Jeremy

And your work is much appreciated!

Daniel

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel

Reply via email to