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 869A51396D0 for ; Fri, 11 Aug 2017 23:50:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2765DE0C5A; Fri, 11 Aug 2017 23:50:24 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 BFCA9E0BE9 for ; Fri, 11 Aug 2017 23:50:23 +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 2480F3416A3 for ; Fri, 11 Aug 2017 23:50:22 +0000 (UTC) To: gentoo-dev@lists.gentoo.org From: Michael Orlitzky Subject: [gentoo-dev] Revisions for USE flag changes Message-ID: Date: Fri, 11 Aug 2017 19:50:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 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 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 38bf87af-197a-41df-b731-f974d7c5dd7e X-Archives-Hash: f4f76db9ac4e8574aa1a1e228d9b5ee2 We have a pull request for the devmanual that will update the revision documentation; namely, when to create a new one: https://github.com/gentoo/devmanual.gentoo.org/pull/67 The comments bring up an issue that I think can benefit from some hindsight. Specifically, the PR says that it's OK to change IUSE without creating a revision, because users can use --changed-use to catch it. My immediate objection to that was that --changed-use is specific to Portage, but let's reflect on the status quo. == The situation now == 1 We tell everyone to update with either --newuse or --changed-use. 2 Developers change IUSE without new revisions. 3 To facilitate (1) and (2), Portage has the --changed-use and --newuse flags. Paludis has a family of "--keep" options to avoid reinstallation, e.g. --keep=if-same-metadata. And pkgcore has its own (different) --newuse flag. 4 There is no specification for the features in (3), and each package manager has taken a different approach. The end result is that Portage users do see the changes made to IUSE without a revision, but at a cost: * They have to pass the "required" --changed-use or --newuse flags to every command. * The same cannot be said for users of other package managers. * Lots of PM code exists to handle this stuff. * Our documentation needs to describe the above (relatively) complicated situation. And with one notable benefit: * We don't need to rename the ebuild to change IUSE, and in theory we can control when rebuilds happen. == New revisions for USE flag changes == I suggest that in hindsight, we can do better. Suppose we require a new revision for every change to IUSE. Then, * We can delete all of the PM code for --changed-use and --newuse and friends. * The documentation becomes much simpler: revbump if IUSE changes. * Users can omit --newuse and --changed-use from their lives. * All package managers now handle IUSE changes properly. * emerge runs a bit faster. This has none of the downsides of the current approach. Of course, it lacks that one benefit -- that you don't have to rename the ebuild when you change IUSE. Now I'll try to convince you that the rename and associated rebuilds aren't that big of a deal. Q. But what about the rebuilds? For most packages, the rebuilds simply don't matter. Unless you're the maintainer of libreoffice, firefox, chromium, etc. -- just do the revision and forget about the (quick) rebuilds. We tell everyone to use --changed-use and --newuse if they want things to work, so they were probably going to rebuild anyway. Q. But what if I maintain firefox, and I need to change IUSE? If the IUSE change isn't important, just make the new revision in a branch and wait to commit it later when there are more changes piled up. If it is important (like if its default value changes RDEPEND), then it would have required a revision anyway. Q. But I work on a team, and we can't all work in different branches. If you work on a massive package and if you're collaborating with others regularly, you can commit the new ebuild masked. This is annoying, but is an extremely rare combination of circumstances. == tl;dr == We would be better off with respect to IUSE changes and revisions if we deleted the --changed-use and --newuse flags right now, and just required developers to revbump when changing IUSE. Package managers get simpler, documentation gets simpler, the user interface gets simpler, and behavior becomes more uniform and predictable. Please let me know what you think.