Frederic Bezies <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 01 Sep 2006 06:26:26 +0200:
> Le 01.09.2006 05:29, walt a écrit : > >> Exciting news, fellow geeks: gentoo upgraded gcc-4.1.1 to 'stable' >> today! > > Ang gentoo 2006.1 is available too. Yes, but release version doesn't really affect a Gentoo user, after installation. It's big news only for those doing new Gentoo installs. >> >> The very first thing I did (of course) was to compile pan using >> gcc-4.1.1 -- and it works beautifully! > > I build it every single week with gcc 4.0.3 :) I've been building it with gcc 4.1.1 for awhile, on Gentoo, but I prefer ~arch (unstable) to the "stale" stuff in stable. Back on Mandrake, I ran cooker for the same reason, and I'd be running the latest unstable/testing/beta/whatever release, no matter what distribution or platform I was running. That's just the way I am. So anyway, yes, pan builds on Gentoo with gcc 4.1.1, but some of us have been doing that for awhile, so it's not news. Only the fact that gcc 4.1.1 finally went stable is news, but that's Gentoo news more than pan news. >> The great thing is that the binary is only 7% bigger than with >> gcc-3.4.x and there are lots of other benefits as well -- but >> I need to read hundreds of pages of documents to find out just >> what those benefits might be. >> >> I'll spend the next day or two reading those docs while I rebuild >> my entire gentoo machine with gcc-4.1.1. > > Upgrade to gentoo 2006.1 it will be simpler. No it wouldn't, as Gentoo users don't "upgrade" to a release. By the time of the release, the regular Gentoo user will already have most of the stuff that comes with that release already merged, and in fact may have /newer/ stuff merged, due to the snapshot-freeze that the release is built and tested against. (In particular, ~arch users are likely to have newer versions, assuming newer versions have been released upstream, of course.) See, part of the whole point of Gentoo is that you upgrade individual applications as they become available, thus never have to do the full system upgrade that other distributions do. Of course, another part of the point of Gentoo is that you get to choose the dependancies (where optional) that a package builds with, normally using USE flags. For example, where a particular package from a binary distribution may be built with both kde and gnome support, thus depending on libraries from both, or built with only support for the "default" desktop environment (DE) choice of that distribution, thus lacking both the dependencies and the optional support of the other DE, so by choosing distribution you choose either full support and dependencies or limit the support for the other choice, with Gentoo, the same package will typically have both kde and gnome (or gtk) use flags, and the person doing the install chooses which support and dependencies the package will have. If they only run KDE (as here, but with GTK as well, in part to support pan), they can set "USE=-gnome kde" and not build those gnome dependencies or have that support. If they run only GNOME, likewise, "USE=gnome -kde" gets the gnome support but won't pull in the KDE dependencies or support. Now Gentoo does have binary packages available for many packages, but they are only updated at Gentoo release time, not as upstream releases new packages. Yes, this includes security updates -- if you choose the binary packages from the old release, that's what you get, even if that package has had security releases since then. The GRP (what Gentoo calls it's binary package program) only updates at Gentoo release, because those packages are only designed to aid in a quick install. After initial install, further upgrades are done via the normal Gentoo compile from source procedure. Similarly, by definition, the GRP binaries shipped with each release use a default set of USE flags and CFLAGS -- they are not nor could they be optimized for an individual installation. Using the example above where both KDE and GNOME support are possible and toggled with the appropriate USE flags, the GRP binary package will have been built with "USE=gnome kde", thus, support and dependencies for both. If you merge that binary package, you'll pull in GNOME dependencies even if you only run KDE and don't want them (or the reverse, you'll pull in KDE dependencies even if you don't want them), because the package was compiled for general use with support for both and won't run without the libraries it linked in for both. Of course, the general packages will also be compiled with general CFLAGS, say supporting a pentium and not making use of newer SSE and the like. For this reason, beyond the initial install, few Gentoo users ever use the GRP packages of any release, because they aren't customized to what they have and want on their own system. Thus again, a Gentoo release matters little to them beyond initial install. Once they have the system up and running, they update as things come along, customizing the build to their individual installation in the process, and what particular Gentoo release is current matters very little. Of course here, we're dealing with a compiler upgrade going stable for the new release as well, and it's not the release upgrade that's the issue, but rather the compiler upgrade. Users can recompile their entire system to get the better optimizations in the new compiler, if desired. However, some only choose to recompile the toolchain (or just gcc itself), and let the rest of the system get recompiled in the course of normal individual application upgrades. The only problem with doing upgrades only as they come is that sometimes packages compiled with one version of gcc don't work quite right (or at all) when used with packages compiled with a different version. This problem is most often seen when an application uses a library compiled with a different gcc, or when two libraries used by the same app are compiled with different gccs. Similarly, the problem doesn't come up as frequently with pure C apps/libraries as it does with C++, due to the libstdc++ library that every C++ app depends on, that's part of gcc's C++ implementation and therefore changes each gcc version. > I would have installed Gentoo 2006.1 instead of my Ubuntu 6.06.1 LTS, > but I won't because : > > - Gnome is older than the one available (2.14.2 in Gentoo, 2.14.3 in > Ubuntu) That's valid. I would have suggested that gnome 2.14.3 might be available for ~arch (that is, unstable), which is what I run, or still masked for testing, but that doesn't seem to be the case. gnome 2.14.2 seemps to be the latest actually in portage. However, because Gentoo is built from source by default, it's generally easier to install from a tarball if desired, or often, to simply move the ebuild of the existing version to your overlay, change the name to reflect the new version, redigest the ebuild so portage doesn't complain about a package that doesn't match its internal checks, and go from there. Where most binary focused distributions require tracing down and installing additional packages (<packagename>-devel or the like) to actually build something from source, because that's the way Gentoo normally does it, those packages are normally not spit into separate packages in the first place, and will already be installed. That's what I do with the weekly pan upgrades. Altho they do make it to portage (now, the early 0.9x ones didn't), it takes a couple days, so all I do is rename the ebuild (it's already in the overlay from the last upgrade I did the same way) and redigest, and an upgrade then builds the new pan, no additional intervention on my part required. Also note that for an individual package, a minor point upgrade often denotes only a security update or bugfix release. With something as big as GNOME, which comes in multiple individual packages, the individual parts are likely to have already been upgraded to the new versions found in the newer GNOME, even tho the gnome metapackage itself remains at the older version number. There are also likely to be publicly available portage overlays, such as the GNOME-focused breakmygentoo.org (referencing the fact that the packages are newer, even more unstable than ~arch, and may break someone's system), that have newer versions of packages if the official gentoo tree is behind. A quick look at their repository... https://svn.breakmygentoo.net/bmg-main/gnome-base/gnome/ It lists an even newer GNOME version, gnome-2.15.4, as available in their overlay tree. > - localization sucks (no french version out of the box for gnome > and other tools) I can't comment on that beyond the following as I know nothing about it. Knowing only English seriously decomplicates life in computer terms. =8^) I'd speculate, however, that the appropriate l10n modules are available either as separate packages within the normal Gentoo tree, or in overlays such as bmg above. Even where that's not the case, as above, the from-source nature means it's much easier to pull in such packages on your own, as in contrast with most binary focused distributions, the dependencies to build from source are normally already there, > - having to build all the modules in order to make firewall work :( Well, you don't have to build /all/ of them, only the ones you will use and their dependencies. =8^) While you do build what you need, you don't have to have the ones you don't use on your system, as is often the case with binary distributions due to the support=dependency problem, as in the gnome/kde example above. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/pan-users
