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 AF6A5138334 for ; Fri, 20 Dec 2019 01:19:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6EADCE0877; Fri, 20 Dec 2019 01:19:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 02E31E0844 for ; Fri, 20 Dec 2019 01:19:49 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id AEA2434D1E8 for ; Fri, 20 Dec 2019 01:19:48 +0000 (UTC) Subject: Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation To: gentoo-dev@lists.gentoo.org References: <3002c804-e70f-5b50-ee38-d91aa7e22fb0@gentoo.org> From: Michael Orlitzky Message-ID: Date: Thu, 19 Dec 2019 20:19:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 417e574e-fc8f-450b-8c4d-d92a72e57526 X-Archives-Hash: 041b2f40744e3a3580cba77484c9e8c0 On 12/18/19 6:28 PM, Michael Orlitzky wrote: > > This *does* happen if you mask virtual/emacs. It *could* happen if you > delete it. > I tested this out. Portage seems OK with the missing dependency, but for the overall plan to work, you have to wait a long time before deleting virtual/emacs; otherwise the upgrade path is broken. With virtual/emacs-26 installed and "old" copies of the elisp ebuilds installed, you get unsatisfied dependencies switching from emacs-vcs to a live slot of emacs. Everyone in that situation must update to virtual/emacs-26-r1, which they can't do after you delete it. And of course you can't mask virtual/emacs in the meantime, because that does kill the PM. New revisions would still be the sane solution, now and in the future, because they don't require investigative journalism to uncover exactly what might go wrong when we bend the rules /this time/. They also don't impose a cutoff date after which upgrading users are screwed. You just automate the revbumps, commit them all at once, and make a pull request against CI to verify that nothing is too borked.