From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1H2N71-0006tp-Lb for garchives@archives.gentoo.org; Thu, 04 Jan 2007 07:34:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id l047WDOm012460; Thu, 4 Jan 2007 07:32:13 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id l047WCNH011334 for ; Thu, 4 Jan 2007 07:32:12 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H2N50-0008Tj-Vr for gentoo-amd64@lists.gentoo.org; Thu, 04 Jan 2007 08:32:02 +0100 Received: from ip68-231-13-122.ph.ph.cox.net ([68.231.13.122]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Jan 2007 08:32:02 +0100 Received: from 1i5t5.duncan by ip68-231-13-122.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 04 Jan 2007 08:32:02 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: quickpkg problems Date: Thu, 4 Jan 2007 07:31:54 +0000 (UTC) Message-ID: References: <20070103030310.GA3184@brego.pewamo.office> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-13-122.ph.ph.cox.net User-Agent: pan 0.120 (Plate of Shrimp) Sender: news X-Archives-Salt: ab1c41dd-bbdc-4c74-ac1a-cdb830293c7b X-Archives-Hash: 215b5bb776bc61a50df91379b95e55b6 Michael George posted 20070103030310.GA3184@brego.pewamo.office, excerpted below, on Tue, 02 Jan 2007 22:03:10 -0500: > I'm updating my system with my normal CHROOT method where I update all > teh packages in a CHROOT and then make packages of them for my real > system. > > For the first time, I am doing this to my amd64 system rather than my > x86 system, and I've had a couple glitches. > > Because /lib and /usr/lib are symlinked to /lib64 and /usr/lib64, the > packages I made in my CHROOT won't extract correctly. It will get to > extracting /lib (or /usr/lib), which is a symlink, and it cannot create > the next level of directories within it because the referenced directory > doesn't exist where the package is being extracted. > > Am I doing something wrong in creating the packages, or in extracting > them? Have you tried FEATURES=buildpkg ? That would seem to be what you are after, and should avoid the system-specific aspects of doing it after-the-fact with quickpkg. The issue is that since quickpkg uses what's actually on the system (or in the root) the package is created on, it will by definition include certain system-specific aspects in the packages as built. Among these are system-specific configuration details such as customized config files and system dirs vs. symlinks. FEATURES=buildpkg is designed to avoid the system-specific aspects while still retaining build flag and USE flag aspects, by binpkging the image as it is fake-installed directly into the temporary image post-install pre-qmerge stage (see the ebuild (1) manpage if you aren't familiar with ebuild stages). Thus, it is the package as it was built, pre-system-specific-configuration, since it's before qmerge and therefore before etc-update. It's also as fake-installed to the temporary location, so the only symlinks included should be the symlinks in the actual package, not anything from the system it's merged to, as will unavoidably be the case with quickpkg. FEATURES=buildpkg also tests the binary package by actually merging from the tarball instead of qmerging from the fake-install image. While that test is by necessity on the system that just built the package, thus not catching all system-specific dependency problems, it at least demonstrates that the created binpkg can be successfully merged under the right conditions, a test missing entirely from the quickpkg method. quickpkg is really designed as a way to avoid a recompile if one is testing an unmerge or upgrade one isn't sure about, in the case the test upgrade does indeed prove unstable or the unmerge ill advised, thus avoiding having to recompile the package you just had merged before the test. While it /can/ be used to transfer packages between systems, thus avoiding the recompile on the other system, that isn't its main intent, and there are certain occasional issues that have to be resolved manually as a result when it is used in that manner. If one is going to be doing routine package transfers as a matter of course, it's therefore far better to use FEATURES=buildpkg, avoiding at least /some/ of the problems. The problems that FEATURES=buildpkg doesn't resolve technically, and there are a number of them that remain as current limitations of the way portage itself functions, Gentoo devs usually nullify thru other means. Very occasionally, there will be a bug or two with a FEATURES=buildpkg built package merging, but where there is, it should be reported (at bugs.gentoo.org, be sure to search and see if the bug has already been filed by someon else) as exactly that, and it should be fixed eventually and if it'll take awhile, the Gentoo package maintainer or portage devs will often provide a workaround to get you moving again. BTW, I recommend FEATURES=buildpkg as one of the poorest advertised "power" features of portage, even for users with only a single installation. The backups it provides certainly simplifies routine sysadmin chores and troubleshooting in a number of ways. Among others, it's /tremendously/ easier to recover from a borked gcc or portage or python, in addition to the fact that it becomes a matter of five or ten minutes' work to merge a different version of a package once you have several binpkged versions available, to see if a particular problem is with one version or all of them. Since the original as-merged version of any file is saved in the binpkg, it's also extremely easy to compare a config file as it currently exists on the system to what was originally merged. As I said, truly an under-appreciated and therefore underutilized power-feature of portage! FWIW, I keep my binpkgs on a dedicated partition, 4 gig sized for plenty of room tho I had it on a 2 gig partition previously. The actual size of a full operating set of merged packages, binpkged, is somewhere around half a gig, here, I'd guess, but as I said, it's convenient to keep several versions of packages around, and while portage now includes the eclean tool to help manage the packages and distdir dirs, one doesn't want to have to clean them out all /that/ often, so over 2 gigs is recommended, with my 4 gig being plenty and to spare, so I'd say 3 gigs. -- 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 -- gentoo-amd64@gentoo.org mailing list