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 EC0391382C5 for ; Fri, 12 Jun 2020 14:51:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B5CC5E0982; Fri, 12 Jun 2020 14:51:09 +0000 (UTC) Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) (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 6173CE0957 for ; Fri, 12 Jun 2020 14:51:09 +0000 (UTC) Received: by mail-ej1-f65.google.com with SMTP id o15so10348683ejm.12 for ; Fri, 12 Jun 2020 07:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OBT1OP2+J20C/i2GFYVrGZd9Cp3ja2UbdgYldWr9YVg=; b=LE8p//4yMQWu4wBvKtIGC5Xzk5VUKx6nwfoU0V1sM9gvYBnYmU078fLV9EaKVLe+gX DVlWoIENlQ4sRd6m2GH02fBYDiXrJ13npM+udTkV4NrJOtHcJmTUf016XVdoANR2ZZFn Uwp+2Rnjs34o8kRiTzDzgMiZFMBEW3jvKLYud6rOXxIptBFA2oDx5evLgIEY2id1a+Uq pU5buQkasUHSmv0eH3cbb/sNAURTFDLfjOhrV2KA1chlYk+sL0ZuZ3BdEmTRqHv+c8Qx miv/XxBAFhwCkKR30mId/D148gYkVpwF1f06hPmFg4pVxXlOB+DeRDs5mTSRo7OZAglz Tfzw== X-Gm-Message-State: AOAM530SxXj9T+BarsqmkNA6RUfbJDxLk21+a+nsm2HMCOlyNNp8y91N QFeo+DDai0BAlP7KuZwr4bDEcHg5kgEi7C/oFoBXyWbD X-Google-Smtp-Source: ABdhPJxB59DHkUJ8MPiddm+34l11IwCnYzR4lVu7tEdHW9eGPyiiB2kYRz0sZqUyWC/BGUUslGEmNwI3u+y4Z8c5gdM= X-Received: by 2002:a17:906:b845:: with SMTP id ga5mr13476189ejb.300.1591973467814; Fri, 12 Jun 2020 07:51:07 -0700 (PDT) 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 References: <9ed9c401-7066-9c6d-8ce4-2ee94a1b903e@web.de> <1c440e09-c19b-0149-058b-21030a4bac8a@users.sourceforge.net> <2027654.irdbgypaU6@lenovo.localdomain> In-Reply-To: <2027654.irdbgypaU6@lenovo.localdomain> From: Rich Freeman Date: Fri, 12 Jun 2020 10:50:56 -0400 Message-ID: Subject: Re: [gentoo-user] "masked by: EAPI 7" trying up update "portage" - how to proceed To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 09193ff6-1171-4cda-b079-b59e0363cde7 X-Archives-Hash: b750cd8504f53843df5bc62e787c35e4 On Fri, Jun 12, 2020 at 10:38 AM Michael wrote: > > On Friday, 12 June 2020 15:00:25 BST Jack wrote: > > On 6/12/20 9:49 AM, Rich Freeman wrote: > > > > > > Ultimately if there was enough interest in something like this the > > > solution would probably be another distro that just repackages Gentoo > > > in a release-based format. Release-based distros have their pros and > > > cons, but they're definitely a better fit for some problems. > > > > > > > What about some sort of tagging? Not bundling or packaging, just > > occasional (quarterly?) labels, with a matrix indicating how difficult > > it would be to upgrade. A hint to folks who tend to update less often > > than they should. A "heads up" that things added or upgraded in the > > past quarter are going to be very difficult to do if you are starting > > with something more than three/five/...? quarters older than that. Of > > course, I suppose if you read the news items as they are released, then > > you should have a pretty good idea of which of them are likely to bite > > you if you wait too long. > > Perhaps I misunderstand this, but isn't it as simple as booting off a LiveCD/ > USB, chrooting, changing profiles, cleaning up world file and letting rip with > a full 'emerge -e' @system, followed by @world for good measure? Once you run chroot you're in the same environment you get when you boot the system normally. It would fix a kernel problem, but not userspace problems. Some people extract a stage3 over their system. That is a very messy solution to be avoided if possible, but that is one way to go about it if you know what you're doing. You'll end up with a ton of orphaned files that could cause problems later. Just doing a clean install and migrating the stuff you want to keep would be much cleaner as suggested in Joost's later reply. As far as the tagging proposal goes, such a thing is definitely possible. The main issues are: 1. Somebody needs to care enough to do it. You'd probably want at least a bit of QA/testing around this. Also, upgrades might still need to be incremental. 2. We need a better solution for hosting non-upstream large files. There are no guarantees that a SRC_URI in an ebuild that was removed from the repo six months ago still works. That applies to upstream too, but it mostly applies to thinks like large Gentoo-hosted patches. We don't necessarily keep them around after the package is gone, and the mirrors purge their copies automatically. If you want to go back in time reliably these need to be version-controlled/etc. There are a lot of things that could be done in this general direction, such as binary repositories. Mostly the issue is that the current approach scratches just about everybody's itch so nobody wants to bother building something in addition to it... -- Rich