From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 846B4138247 for ; Mon, 4 Nov 2013 20:02:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FD0DE0B45; Mon, 4 Nov 2013 20:02:32 +0000 (UTC) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 895DDE0B1A for ; Mon, 4 Nov 2013 20:02:31 +0000 (UTC) Received: by mail-yh0-f43.google.com with SMTP id v1so1198992yhn.2 for ; Mon, 04 Nov 2013 12:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=eNJ+71ko7B/SJn9PR2y9ygIHxP4VqX/TmPq7Lf416OA=; b=Nd3a3cqkWm2/w3mi6fPfue3gaM6rDL/Z/7zLyPNrkjxB/mtBxAklXGZTu5SGM/ijq3 5XB1DZY1YZd3aEp9V2PVjE8P+Afh3MYF5GOmJqDkcCDRDg6NcdQhE8HYbhhzkMAgMtpi wF8gS0XsRjZSpqP+1YDVcuIwsZ3X6novcaQIILYvp2CbIj4Y3ySIUWaDe88PYRdHqcYQ +CuhaC6rAH5g8GUFi4zXpbC+RPKMlAbSqm8xU7Jhe4y4X6e++Kr1QAbY6H0tjBXRaJfd IN9luoin9OvXe4+aoI2JAaS28PfAld4YAJK2MBIWL+Xn0YXnWlIp5xO1jMx13kYu7n7g iang== X-Received: by 10.236.130.138 with SMTP id k10mr15028560yhi.31.1383595350625; Mon, 04 Nov 2013 12:02:30 -0800 (PST) Received: from [192.168.2.5] (adsl-98-95-151-14.jan.bellsouth.net. [98.95.151.14]) by mx.google.com with ESMTPSA id v22sm29442147yhn.12.2013.11.04.12.02.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 12:02:30 -0800 (PST) Message-ID: <5277FD54.9020105@gmail.com> Date: Mon, 04 Nov 2013 14:02:28 -0600 From: Dale User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: Tom Wijsman , gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Official way to do rolling update (Was: Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec) References: <20131104051518.51efd36c@gentoo.org> <52775FD3.7000102@sporkbox.us> <20131104112632.0c7ff3de@gentoo.org> <52778DDC.7080407@gmail.com> <20131104132834.27fe7dfb@TOMWIJ-GENTOO> In-Reply-To: <20131104132834.27fe7dfb@TOMWIJ-GENTOO> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------000004010402060404010109" X-Archives-Salt: ee507e0e-d56a-4d18-9506-b4d0e7f50b19 X-Archives-Hash: b330d64f992f5d78c826fc85c64a68be This is a multi-part message in MIME format. --------------000004010402060404010109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tom Wijsman wrote: > On Mon, 04 Nov 2013 06:06:52 -0600 > Dale wrote: > >> But after a person has used Gentoo a while, they figure out what >> process leads to the most stable update process. > > Do they? What do you consider a stable update process? I consider it stable when things work as they should except for known bugs upstream. Obviously if there is a known bug upstream then that bug will likely filter right on through to Gentoo. That said, if the Gentoo devs can correct a issue, they do so but that is not always the case either. > > > I come across users on a daily basis which > > - haven't upgraded their system lately because they're not good at it; > - get into unclear slot conflicts locking them out of updates; > - some build failure disallows their dependency graph from completing; > - managed to finally update, but don't know about depclean; > - managed to finally depclean, but don't know about eclean. > > It involves a lot of prior knowledge, manual checking and what in order > to be able to update the system; I wouldn't label this "stable", but > rather "dependent on the person updating it" and to some extent even > "dependent on whether the person memorized all the docs and/or gets > helped or get it told in the support channels". > > There are some improvements possible in these situations; I'm planning > to discuss some ideas and write some patches where possible, and I > hope other people jump on the bandwagon to help improve user experience. > > That doesn't mean I consider it bad or that we need to go hand holding. It does require prior knowledge which is why I said what I did. I used to do emerge -u world way back when. That would SOMETIMES lead to issues because it may not go deep enough. Then I added -D which helped but from time to time would still miss something. So, I added the backtrack to make.conf. That improved things even more. Over time, I realized that I needed to add the -N option so it got added to the command. As it is now, I have that knowledge. I learned some of that the hard way. You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are. That would be emerge -uaDN world. Right now, that has lead me to the most stable OS. When it doesn't, I do a emerge -e world if nothing else fixes the issue. That doesn't happen as much as it used to because either Zac is tweaking portage or devs are doing better on the ebuilds. Heck, it could be both since both need to work well to get a good end result. > >> The only way to get a more stable system is to do a emerge -e world >> and update that way. At least that has been my experience so far. > > I have never needed this; I wonder whether there exists an example case > for this, I only see this used when someone changes compiler / flags > and wants to ensure the whole system turns into rice. * I have needed this more than once in the past. I would run into a problem and recompiling the obvious packages didn't correct the issue. Doing a emerge -e world would fix the issue. Obviously something fell through the cracks that my usual command would miss but the -e would catch since it does all packages. I never reported the issue since I don't know what specifically fixed the issue. There is no way for a person to figure out if it is a portage issue, ebuild issue or some other issue. I didn't see the point in filing a bug because there is no way to track down the source of the problem. This is my experience. By all means, if you do something different and it works for you, do it your way. I'm going to continue doing what works for me. If someone asks me how I do things, I'll recommend the same command/settings I use just like I'm sure some other old timers will do. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! --------------000004010402060404010109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tom Wijsman wrote:
> On Mon, 04 Nov 2013 06:06:52 -0600
> Dale <rdalek1967@gmail.com> wrote:
>
>> But after a person has used Gentoo a while, they figure out what
>> process leads to the most stable update process.
>
> Do they? What do you consider a stable update process?

I consider it stable when things work as they should except for known bugs upstream.  Obviously if there is a known bug upstream then that bug will likely filter right on through to Gentoo.  That said, if the Gentoo devs can correct a issue, they do so but that is not always the case either.

>
>
> I come across users on a daily basis which
>
>  - haven't upgraded their system lately because they're not good at it;
>  - get into unclear slot conflicts locking them out of updates;
>  - some build failure disallows their dependency graph from completing;
>  - managed to finally update, but don't know about depclean;
>  - managed to finally depclean, but don't know about eclean.
>
> It involves a lot of prior knowledge, manual checking and what in order
> to be able to update the system; I wouldn't label this "stable", but
> rather "dependent on the person updating it" and to some extent even
> "dependent on whether the person memorized all the docs and/or gets
> helped or get it told in the support channels".
>
> There are some improvements possible in these situations; I'm planning
> to discuss some ideas and write some patches where possible, and I
> hope other people jump on the bandwagon to help improve user experience.
>
> That doesn't mean I consider it bad or that we need to go hand holding.

It does require prior knowledge which is why I said what I did.  I used to do emerge -u world way back when.  That would SOMETIMES lead to issues because it may not go deep enough.  Then I added -D which helped but from time to time would still miss something.  So, I added the backtrack to make.conf.  That improved things even more.  Over time, I realized that I needed to add the -N option so it got added to the command.  As it is now, I have that knowledge.  I learned some of that the hard way.

You are right, it does require prior knowledge and as a user gets that knowledge, they likely end up where Alan, Duncan and myself are.  That would be emerge -uaDN world.  Right now, that has lead me to the most stable OS.  When it doesn't, I do a emerge -e world if nothing else fixes the issue.  That doesn't happen as much as it used to because either Zac is tweaking portage or devs are doing better on the ebuilds.  Heck, it could be both since both need to work well to get a good end result.

>
>> The only way to get a more stable system is to do a emerge -e world
>> and update that way.  At least that has been my experience so far.
>
> I have never needed this; I wonder whether there exists an example case
> for this, I only see this used when someone changes compiler / flags
> and wants to ensure the whole system turns into rice. *

I have needed this more than once in the past.  I would run into a problem and recompiling the obvious packages didn't correct the issue.  Doing a emerge -e world would fix the issue.  Obviously something fell through the cracks that my usual command would miss but the -e would catch since it does all packages.  I never reported the issue since I don't know what specifically fixed the issue.  There is no way for a person to figure out if it is a portage issue, ebuild issue or some other issue.  I didn't see the point in filing a bug because there is no way to track down the source of the problem.

This is my experience.  By all means, if you do something different and it works for you, do it your way.  I'm going to continue doing what works for me.  If someone asks me how I do things, I'll recommend the same command/settings I use just like I'm sure some other old timers will do.

Dale

:-)  :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

--------------000004010402060404010109--