Sergio Polini <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 28 May 2006 19:25:51 +0200:
> Sure, but when I used FEATURES=buildpkg, emerge --sync took a long time; > i.e. after emerging I was prompted to call fixpackages and it took a > loooong time. You gotta understand what they are saying that for and act accordingly. What happens is that sometimes packages will move from one category to another, or be renamed or replaced with something of a different name. When you sync the tree, portage gets a notice of the move and adjusts its tracking of what you have merged (the /var/db/pkg database) to match what's now in the tree. In doing so, it not only adjusts the packages that moved themselves, but the dependencies. An example would be libgif/libungif. A gif patent expired a year or two ago. While it was in force, libungif provided a patent-free workaround for those in locations where the libgif package wasn't legal due to the patent. After it expired, there was no longer a need for a distinction, as the libraries were designed to be drop-in replacements for each other, only the one didn't include the patented functionality. Thus, Gentoo was able to remove libungif. What they did was tell portage that libungif was now libgif. Because the libraries were drop-in replacements for each other, anything that depended on libungif could now be changed to depend on libgif instead. The devs did that in-tree, but portage had to adjust its dependency database so it didn't get out of sync with what the tree said the dependency was supposed to be. The catch is that binpackages include copies of the ebuild used to create them, and said ebuild specifies dependencies. In ordered to use those packages with the updated tree, they too have to be updated. This takes awhile, as you noticed, so it's not handled automatically unless you have FEATURES=fixpackages set. The key thing to realize, however, is that as long as you aren't actually trying to merge those binpkgs, they are fine as they are. There's no reason you have to run fixpackages every time something changes in portage that asks you to, unless you are going to actually be using those binpkgs. Further, in the event of a crash and a need to actually use those binpkgs, you could use the manual untar method regardless of what the attached ebuild said, because it bypasses that. If you were actually using portage to do remerge the binpkg, you could run fixpackages at that point, before you actually remerged anything. If you forgot to do so, it would simply give you an error, which would probably get you thinking "Hey, I gotta run fixpackages before this will work, as I had not yet done so." As for the fixpackages process itself, you are absolutely correct, currently stable portage (2.0.5x) takes a VERY VERY long time, because it goes over EVERY SINGLE CHANGE EVER MADE EVERY SINGLE TIME YOU RUN THE THING, even ones that were made the LAST time you ran fixpackages and thus don't need to be made again, even ones made before you were even running Gentoo, so there's no way they could ever apply to you! As such, with stable portage, it's actually best NOT to run fixpackages until you have to, because it redoes everything it did the last time anyway. Fortunately, fixpackages is much smarter with the current ~arch portage (2.1 release candidates ATM). With 2.1, it timestamps the last time it ran fixpackages, and skips everything before that, so it only processes what has changed since the last time it ran. Basically, that means that if you run it every time it tells you to, it will only have the changes that happened to come in with that portage sync to worry about, and it is MUCH MUCH MUCH MUCH FASTER!!! Usually, it only has a couple things to change, instead of going thru the probably hundreds of changes that have happened since the first move portage ever had. As a result, it's actually practical to add FEATURES=fixpackages now, and let portage manage it automatically, as it's fast enough the sync normally takes longer than the fixpackages does. You can still do manually, and skip doing it until you need to remerge one of those packages, if desired, but there's really no need to do so. Letting portage handle it automatically now actually makes sense. FWIW, 2.1 is targeted at stabilization for use with Gentoo 2006.1, which is targeted for July. This is only one of a number of HUGE improvements in 2.1, and you guys still running 2.0.5x have a lot to look forward to when 2.1 goes stable! =8^) Don't forget to reread the emerge manpage, the make.conf manpage, and make.conf.example when it happens, as portage will keep doing things the slow old way in a number of cases, if you don't properly configure it to take advantage of the new features. In particular, pay attention to FEATURES=confcache (especially anyone using KDE!) and FEATURES=-metadata-transfer (that one's on by default, so you use - to turn it off, it's now faster to regenerate the metadata than it is to transfer it, for many people). FEATURES=parallel-fetch can also be useful, and FEATURES=user-fetch is something anyone who has ever wondered about the security implications of exposing root to the wilds of the net during the fetch phase should definitely appreciate! There's also a new tool in the matching gentoolkit, also in -rc now. It's called eclean and it can be used to help clean out the staleness in both $DISTDIR (the portage tarball cache location) and $PKGDIR. There are also a couple changes to the way emerge works. The old way still works for 2.1 but will be removed later, and portage now warns you if you use the old way. emerge actions (sync, metadata, fetch, etc) now want -- in front of them, as emerge --sync, and a couple make.conf variables have changed their name. Again, the old way will still work for now, it just generates a warning, so no worries, but there will be some things that you'll need to change eventually, probably before 2.2. That make things a bit clearer, now, and buildpkg a bit more tolerable? It should, as it certainly helps make buildpkg tolerable here! =8^) -- 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 -- [email protected] mailing list
