On Aug 23, 2005, at 6:21 PM, Daniel Johnson wrote:
An XCode Legacy Tools package is now available on ADC which provides, among other things, gcc 2.95.2 and gcc 3.1 for Tiger (and Panther). If a Tiger user installs this, fink will want to install it's gcc3.1 package since it's version number is higher than the virtual gcc3.1 package. This is likely not the desired behavior. :)
Fink's gcc3.1 package installs into the fink prefix (usually /sw), so it's not as if there's a critical problem with Fink's GCC overwriting Apple's GCC 3.1. It just means a bit of extra compile time and installation space, when they end up installed in parallel.
I wouldn't object to synchronizing the version numbers of the GCC 3.1 virtual package and the real package. Currently the virtual one is at version '3.1' and the real one uses the build number '1175', it should be possible to have them both use '1:3.1-1175' for example. Perhaps there is a pressing reason why they need to be different?
One problem, however, is keeping these versions in synch. If there's a minor change to the real package, and the revision needs to be bumped, should the revision of the virtual package be bumped too? And how will the virtual package engine know when its revision needs a bump?
Another potential problem arises if there's a particular package somewhere that needs specifically the Apple or Fink version of GCC 3.1 (assuming there turns out to be any bug or other difference in one of them).
Any ideas how to get around these issues? If it's not reasonably easy to do so, it might be best to just live with the imperfect but working solution we have now, and simply deal with the extra time and space needed to install Fink's gcc3.1 in parallel.
Dave
PGP.sig
Description: This is a digitally signed message part
