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 03ACF1396D0 for ; Sat, 12 Aug 2017 04:22:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5B603E0DEE; Sat, 12 Aug 2017 04:22:40 +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 04FD4E0D29 for ; Sat, 12 Aug 2017 04:22:39 +0000 (UTC) Received: from [IPv6:2001:44b8:4197:2800:a37a:5ec1:db17:1e49] (2001-44b8-4197-2800-a37a-5ec1-db17-1e49.static.ipv6.internode.on.net [IPv6:2001:44b8:4197:2800:a37a:5ec1:db17:1e49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kensington) by smtp.gentoo.org (Postfix) with ESMTPSA id 5B7E23419C7 for ; Sat, 12 Aug 2017 04:22:38 +0000 (UTC) Subject: [gentoo-dev] Re: Revisions for USE flag changes References: From: Michael Palimaka To: gentoo-dev@lists.gentoo.org Message-ID: <99777392-a964-3865-c26b-ae47b443aa13@gentoo.org> Date: Sat, 12 Aug 2017 14:22:33 +1000 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Archives-Salt: 7ab82c78-2ec2-42a9-a115-4b397e4b55eb X-Archives-Hash: 36a3e499e7cf3b31979fea153cb795dc On 08/12/2017 09:50 AM, Michael Orlitzky wrote: > 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. I really wish people would stop trotting out this false argument. Not everyone has the latest and greatest hardware. Rebuilds have a real cost to end users and as such we should use them wisely. > We tell everyone to use --changed-use and --newuse if they want > things to work, so they were probably going to rebuild anyway. Who tells everyone to use these flags and where? I never use these flags day-to-day, only if I need that specific functionality for that reason > 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. Please stop trying to force workflows on people. Using that same logic, I can make the IUSE change in-place and it would be propagated in the next version bump. > 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. Again, let's not try and tell teams which workflow works best for them. > == 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. I disagree with this change because your proposed benefits don't hold up: > * We can delete all of the PM code for --changed-use and --newuse and > friends. As pointed out by Brian, we still need at least --changed-use even if IUSE changes in-place are banned. > * The documentation becomes much simpler: revbump if IUSE changes. We should base our policies around the cost / benefit of said policy, not how many or few words we need to write in the devmanual about it. > * Users can omit --newuse and --changed-use from their lives. They already can. > * All package managers now handle IUSE changes properly. If you want to see consistent behaviour in how package manages handle IUSE, I suggest sending patches for PMS. I don't see any problem in portage/paludis/pkgcore handling things differently. That is the point of having different package managers, after all. > * emerge runs a bit faster. Why will it run faster?