-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/3/10 12:12 PM, Jack Howarth wrote: > Okay. Let's do this in a democratic fashion. We > can have a poll on JF's proposed approach to create > a gcc split-off among the fink developers who are > BuildDepends on the gcc4x packages in theirs. The > proposal is... > > ------------------------------------------------- > other pkgs : I gave you in my comment below the > example of gettext-bin _ a basic pkg, maintained > by fink-core ... > > how to install: fink install gcc-4.X.Y > > But the intent is clearly to accelerate > upgrading , in order for users an pkg submitters > not to stay stuck with museum-gcc's, > just because they forgot to check for the > presence of a new number, ending up in a > situation where about every pkg uses its > own version of gcc, for purely accidental > reasons. > > The suggestion does have the slight disadvantage > that new pkgs, IF they want to depend on a > specific version of gcc (but no pkg takes such > precautions against upgrades of Apple's compilers), > have to Depend on gcc4X-compiler, and put > %p/lib/gcc4.X/bin first in PATH > > But existing pkgs don't have to be modified > (provided the existing gcc4X pkgs are not refactored !), > assuming just that in your upcoming gcc-4.4.4 pkg > you add "gcc" itself to the Conflicts and Replaces. > > This would still cause slight trouble with the pkgs still > depending on gcc42 or gcc43 , users having to manually > install that dep.. I'd think there are few such pkgs, > and that there are anyway probably reasons to upgrade > most of them. > But some seem to have reasons (dx, pdftk). > Probably it would be worth, for those 2 pkgs, to add also > to gcc42 and gcc43 a Conflicts/Replaces for "gcc"... > Hopefully very few users still need those old versions, > so few would have to re-compile ... > And the same thing would anyway have to be done > oterwise for the upcoming gcc-4.6 for those pkgs.. > > This is "biting the bullet" once; after this, no more trouble > ever of this sort. > > Jean-Francois > ---------------------------------------------------- > > If there is a consensus that the majority of fink developers (who > are the end-users) are okay with this and that I will > be protected from the flak when some users are forced > to build gcc42, gcc43, gcc44 and gcc45 after a > 'fink selfupdate', I am willing to consider implementing > it. Opinions? > Jack > ps My main concern is that developers will have buyer's > remorse if they automate the BuildDepends on gcc such > that the newest FSF gcc is always used and they suddenly > discover package X is incompatible with the compiler > changes or tickles a bug in the compiler. Also, we will > have to propose some convention for patch replacement > such that a package that BuildDepends on gcc automatically > checks its version and sets LDFLAGS=-L%p/lib/gcc4.x/lib > based on the version returned. In short, this is not > a trivial undertakening and everyone will have to buy > in. >
Perhaps I'm missing something here (maybe it was in one of the other threads) but how is it possible _not_ to have to update the Depends: of packages that use gccX when X is changed? BuildDepends are well and good, but what about the libraries from FSF-gcc that get linked? (i.e. why one reason we have gccX-shlibs for multiple X) Are they going to be refactored to maintain their install_name across versions (and then what about ABI compatibility)? Or will there no longer be any linkage? Otherwise, it seems like we're still going to have to have packages Depend on a particular gccX-shlibs. - -- Alexander Hansen Fink User Liaison -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvfAtAACgkQB8UpO3rKjQ9PmgCggUSCuGqidw3/FQHzj2Kov3vC J4IAoIkM/W1ZUjA5o5Hfx/cXIqBeRaRl =yLN9 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
