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.60) (envelope-from <gentoo-user+bounces-45838-garchives=archives.gentoo.org@gentoo.org>) id 1Fyzuj-00044s-R0 for garchives@archives.gentoo.org; Fri, 07 Jul 2006 23:39:14 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k67NYsPe031889; Fri, 7 Jul 2006 23:34:54 GMT Received: from ilievnet.com ([84.21.204.200]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k67N0agf000863 for <gentoo-user@lists.gentoo.org>; Fri, 7 Jul 2006 23:00:36 GMT Received: (qmail 12882 invoked from network); 8 Jul 2006 02:00:31 +0300 Received: from unknown (HELO ?10.0.1.11?) (10.0.1.11) by 0 with SMTP; 8 Jul 2006 02:00:31 +0300 Message-ID: <44AEE78B.3050002@ilievnet.com> Date: Sat, 08 Jul 2006 02:00:27 +0300 From: Daniel Iliev <danny@ilievnet.com> User-Agent: Thunderbird 1.5.0.4 (X11/20060704) Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Things that can be improved References: <44AEB475.8000702@maestroprogramador.com> <7573e9640607071412u6ef9750btfceae4bacf5f9dde@mail.gmail.com> In-Reply-To: <7573e9640607071412u6ef9750btfceae4bacf5f9dde@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 8f834b30-e40b-457d-880d-624df6b5bd53 X-Archives-Hash: aa693d0e6323f2ecaaa200539c05df57 Richard Fish wrote: --snip > It is far more likely that you could break python (and thus portage) > from a mishandled gcc or glibc update. But there is already a > recovery option available in this case; if you have buildpkg in your > FEATURES, you will already have a backup copy of > portage/python/gcc/glibc/everything else in $PKGDIR. Even if portage > is broken, you can extract those tarballs to get back to a working > configuration. Of course, this assumes that tar and bzip2 > work...otherwise you are down to booting from a live CD. --snip Well, correct me if I'm wrong but it think it's not quite true. I *think* if you have buildpkg in your FEATURES, you will get binary packages in your $PKGDIR with the new, updated versions. Those that you have just emerged , not the previous ones which you would like to have backed up. Having the newly compiled packages $PKGDIR can be exported via http server as an alias for example: "alias /packages /usr/portage/packages" and used as PORTAGE_BINHOST="http://192.168.0.1/packages in /etc/make.conf on a buch of other machines. This way one doesn't compile on every single machine but use the already compiled packages. Very useful if you have many equal (as hardware) machines with the same settings in "make.conf". The only way (I'm aware of) to make a semiautomatic backup of an already installed package is to use "qpkg" "qpkg" is available in "app-portage/gentoolkit" On the subject. I would say that I like end use Gentoo for two main reasons: 1) it is a binary distro, which means optimization, customization and speed. 2) gentoo doesn't mess with MY config settings without asking if it should. I would hate if some automated tool is ****ing MY settings without my knowledge. About the "damaged portage" issue...well, I agree with others who think it is highly unlikely a damaged version to go out and get available for the users. My "wish list" 1) I would like to see an implementation of "PAUSE". I mean, during most of the emerges there is not only one package to be emerged. Some of the packages have instructions for additional post installation steps that the user should take. Well, I think there should be a "FETURE", a flag to "emerge" or some other mechanism to tell portage to wait for confirmation if the ebuild gives such information. 2) More control over portages verbosity. Most of the time I only need to see the portages messages, not all the compilation stuff. The later is interesting to me only if the compilation fails. 3) I hate ebuilds that are rewriting variables that I have set. For example I couldn't find a way to compile mplayer with "--disable-runtime-cpudetection", many packages overwrite C(XX)FLAGS. They change "-O3" to "-O2" etc. "Gentoo is about choices" but why this happens? My opinion is that portage should warn about the "too aggressive setting" but to let ME chose to change the settings or not. -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list