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