The suggestion itself was missing in Jack's message. It was that the pkg containing the symlinks in %p/bin could, for future gcc4X pkgs, be just called "gcc".
Existing fink pkgs would obviously not be affected, since all their deps and bdeps involve gcc4X. >> The suggestion does have the slight disadvantage >> that new pkgs, if they want to depend on a >> specific version of gcc, have to Depend on gcc4X-compiler, >> and put %p/lib/gcc4.X/bin first in PATH But this is also an advantage, since it avoids Bdeps on (mutually conflicting) gcc4X pkgs _ thus allowing even parallel builds of on one side a pkg depending on gcc45 and on the other side on gcc46. >> >> 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. >> On 5/3/10 12:12 PM, Jack Howarth wrote: >> 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. Of course. As a rule, pkgs should depend, as said above, on a fixed version, and set PATH appropriately. (but _ for pkgs I maintain, there are a couple (say saclib, qepcad) where I might be tempted to examine the possibility to just let them depend on "gcc" >> 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. Don't understand this. Existing pkgs should not be touched. > On 03 May 2010, at 19:07, Alexander Hansen wrote: > 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? gccX continues to exist, even if a "gcc" pkg comes up. > > 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? The -shlibs splitoffs are not affected by this suggestion > > Otherwise, it seems like we're still going to have to have packages > Depend on a particular gccX-shlibs. sure ! Jean_francois ------------------------------------------------------------------------------ _______________________________________________ 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
