On Mon, Aug 11, 2008 at 03:53:47PM -0400, Benjamin Reed wrote: > Jack Howarth wrote: > | Benjamin, > | If it is a 10.5-gcc-4.2 branch, I would assume by default it > | would be an opt in. Besides, I would surprised if Apple doesn't switch > | the default compiler to gcc-4.2 for Snow Leopard so we will likely > | want to do that for 10.6 anyway. Why can't we just create a 10.5-gcc-4.2 > | branch, dump unstable over into it and set fink to build with gcc-4.2. > | Then fink developers could play with that branch at their leisure. > > My point is, if we add support for users to opt-in to GCC 4.2 through > fink.conf, we don't need a branch! > > People can continue to use fink just as it is now. People who want the > performance update can move to 4.2, and can submit patches with fixes > (or bug reports) for packages as-needed. > > I think it is a bad idea to have another all-or-nothing branch, it was a > pain for 3.3->4.0, it was a pain for pangocairo; it's a lot of work, and > the only reason to do it was because it was a forced catastrophic change > and it was something we couldn't do without a lot of pain for the user > in the meantime. Making a branch should be a last resort, not the default. > > | Also, I don't think performance improvements is a small deal overall. > > They are not a small deal for *you*. But that guy with an 800Mhz G4 who > only uses fink for 2 programs that he runs once a month is not > interested in spending 3 days downloading Xcode 3.1.1 and/or compiling a > new gcc just to get a performance update he doesn't need or want. Fink > has a very *very* wide range of use-cases, and performance is only one > of them.
This is a very important point. I'd say many/most fink users care little to not-at-all about getting maximum performance nor do they use packages where raw performance is even a really noticeable issue. The common user complaints are about lack of binaries and having to compile even a quick source or do an x11 upgrade that doesn't even require compiling at all, but nobody says "why aren't we using -Os everywhere"? That latter would be a quick help even without requiring a new compiler or distro-fork. > | My instinct is that most everything will build fine that uses recent > | upstream sources. Using a gcc-4.3 would be more problematic. If anything > | I suspect the biggest effort will be removing any patches added to > packages > | to build on the older gcc 4.0.1. > > Again, I'm not saying not to work on making things work with 4.2. > Performance is good. I'm all for it. But, Fink's strength has been in > making transitions easy for users. Rebuilding everything all at once > because we said so is not an easy transition for the users. [...] > It should be possible to make patches that continue to work with older > gccs, in which case it should not be necessary to do that. 4.2 is > ABI-compatible with 4.0.1 binaries, right? I haven't heard anything about ABI incompatibility in 4.0 vs 4.2 vs 4.3 (we alrady mix'n'match them). Portable patches are actually a good idea, because upstream can include them for the future. Again comes back to not *forcing* a new compiler on *everything* just because a handful of other packages want (or maybe need) it. > It's no different than building against OSX 10.5.4. It's assumed that > if you built fink stuff on 10.5.4, your binaries probably won't work on > 10.5.0. Going forward in a binary-compatible way doesn't require > revision bumps. Only changing ABI or library compatibility or some such > does. Well, we kind-of assume that within a 10.X series it's forward/backward, but again it would be easy to use our normal dependency mechanisms to require at least a certain baseline version of whatever platform or virtual package. > In the end, Fink's most precious resource is time. A lot of us don't > have time to work on all-or-nothing big projects; look how long it to > for pangocairo to get finished, even when a not insignificant number of > people were spending many hours on it. It is not a good idea to do a > big branch and dump it on everyone at once unless there is no > alternative, and in this case, I think there is definitely an alternative. > > Those who are performance-minded can always opt-in, but it's not worth > forcing everyone to do it, when it *also* means forcing maintainers into > spending a bunch of time they already don't have on the transition, and > forcing users to spend significant time on something they may or may not > want. I wish there were stronger words than "I completely agree". Fink's primary audience just wants stuff to work with a minimum of time and hassle. Maintainers already have a zillion hoops to jump through and are already being forced to maintain packages for platforms they don't have and accept patches from others "here, this fixes X on machine type Y" that they don't understand. Forking the distro should *never* be considered until all other approaches have actually been tried and proven to fail hopelessly and badly. Pangocairo took over 18 months just to get to a place where we got "most things" to build "at least once for one user". That was only a few hundred of our few thousand packages and involved a well-defined set of issues and solutions to them. 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-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
