From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2EE0D1382C5 for ; Fri, 12 Jun 2020 15:05:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0C02DE09C7; Fri, 12 Jun 2020 15:05:08 +0000 (UTC) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 89176E0972 for ; Fri, 12 Jun 2020 15:05:07 +0000 (UTC) Received: by mail-qk1-f194.google.com with SMTP id v79so9232572qkb.10 for ; Fri, 12 Jun 2020 08:05:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:reply-to:subject:to:cc:mime-version :in-reply-to:message-id:content-disposition :content-transfer-encoding; bh=+gq1qG+Cx+KrsCV+utE+MUbzxnGkdR25JgEpKqxJLgg=; b=lihd8AfcKEg9IOGaWBbEpebZeNI5CrCLbeNa5yZkqv1J6pIz4YSeTWYuvsKMmvAa7K BjviHbfyvnmWJ7gnr1dbzc08b6WBeQhjyj41TVI/yKU3oZ8xJU9OpXazUD5PqvX8vNug YRWhxRh+ZtYeAzx0uD/Vvqr95YXfx7+CPQ0SdN0S4jNbVZn4mVQApRL1WAB8z/lFnWUa BCVOUrfQOqhCaf9OrQuJ4ONoa+i8ECCfL1IXDXi+KSlGOF7M5nZmdAQyyXzIsndsPjQa 2mTFzuwW4c/mogMtqtch0MGksCCQmP8KlSYLdkafD2s2CJJwLcbdYyOOVdU3CGeCaqGt 2XCA== X-Gm-Message-State: AOAM532n9NTkfBz0hOH6e7ZWm4xAbxz0CxwMGpK5mt+ohNOAwLfZgvSv kPOsI31+phOuuEpRYpaiH4hK653Hy4o= X-Google-Smtp-Source: ABdhPJzy4A5mIsPyiVoi06vDjLtFFWDJ1VIXUfA5Mz3RVp0MGvVfcj1lluudIJ3NON4uzDtnjfgjyg== X-Received: by 2002:a37:cca:: with SMTP id 193mr3458050qkm.208.1591974305674; Fri, 12 Jun 2020 08:05:05 -0700 (PDT) Received: from ffortso9 (c-76-23-130-96.hsd1.ct.comcast.net. [76.23.130.96]) by smtp.gmail.com with ESMTPSA id x13sm4520856qkj.36.2020.06.12.08.05.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 08:05:05 -0700 (PDT) Date: Fri, 12 Jun 2020 11:05:04 -0400 From: Jack Subject: Re: [gentoo-user] "masked by: EAPI 7" trying up update "portage" - how to proceed To: gentoo-user@lists.gentoo.org Cc: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <2027654.irdbgypaU6@lenovo.localdomain> X-Mailer: Balsa 2.5.10-65-geb847a2f0 Message-Id: Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f305aca5-006d-4213-ab0b-d638a5d407b9 X-Archives-Hash: 668d0e45210e9d9000cb27f92055c0f1 On 2020.06.12 10:38, Michael wrote: > On Friday, 12 June 2020 15:00:25 BST Jack wrote: >> What about some sort of tagging? Not bundling or packaging, just =20 >> occasional (quarterly?) labels, with a matrix indicating how =20 >> difficult it would be to upgrade. A hint to folks who tend to =20 >> update less often than they should. A "heads up" that things added =20 >> or upgraded in the past quarter are going to be very difficult to do =20 >> if you are starting with something more than three/five/...? =20 >> quarters older than that. Of course, I suppose if you read the news =20 >> items as they are released, then you should have a pretty good idea =20 >> of which of them are likely to bite you if you wait too long. >=20 > Perhaps I misunderstand this, but isn't it as simple as booting off a =20 > LiveCD/ USB, chrooting, changing profiles, cleaning up world file and =20 > letting rip with a full 'emerge -e' @system, followed by @world for =20 > good measure? The issue I was addressing is not how to upgrade, but whether Gentoo =20 could have some sort of release cycle decreasing the chance of delayed =20 updates becoming a nightmare. Unfortunately, it seems there isn't much =20 point, because folks who delay upgrading until it becomes painful, if =20 not close to impossible, probably won't take such hints anyway. However (and I"m just musing here) I wonder if you could do an "emerge =20 --sync," drop a new stage 3 tarball over the existing installation, and =20 then do "emerge -e @system" followed by "emerge -u @world?" (including =20 other appropriate parameters.) To answer a question from a different sub-thread, if you can =20 successfully update @world, there's no need to do @system first. =20 However, if @world has too many problems, it can be easier to upgrade =20 @system, and then work through the rest a few packages at a time.