From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E64A41387FD for ; Tue, 1 Apr 2014 11:26:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73DECE09B8; Tue, 1 Apr 2014 11:26:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 67C37E0984 for ; Tue, 1 Apr 2014 11:26:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B344C33FB8C for ; Tue, 1 Apr 2014 11:26:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5.5 tests=[AWL=-0.893, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.566, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC1GMjn7JSlB for ; Tue, 1 Apr 2014 11:26:41 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 5ECEC33FB49 for ; Tue, 1 Apr 2014 11:26:41 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WUwpq-0006Yg-Bo for gentoo-dev@gentoo.org; Tue, 01 Apr 2014 13:26:30 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Apr 2014 13:26:30 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 Apr 2014 13:26:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: Stable masks on multilib packages Date: Tue, 1 Apr 2014 11:26:17 +0000 (UTC) Message-ID: References: <20140401001617.42fdc3bc@pomiot.lan> <5339F5B8.8000305@gentoo.org> <20140401075411.2e71b0fa@pomiot.lan> 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-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 2ae6aff /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: ecd8f7b9-2b27-4c63-80c8-e1a114b5c04c X-Archives-Hash: 6eaeb9c0ade64a41db712e8eb2118a05 Michał Górny posted on Tue, 01 Apr 2014 07:54:11 +0200 as excerpted: > Something like this, yes. Once all packages are migrated and some time > passes, we unmask all the flags locally and do a repoman run. We find > out what needs to go stable, report bugs, wait and repeat. The big question on the user side is how many times we're going to have to rebuild the same code, just because people are messing with multilib stuff. Masking all the now unmasked is going to force yet another rebuild on stable users, who presumably are stable in part because they /don't/ want all those "pointless" rebuilds. Altho I'm ~arch so stable masks won't directly affect me, but at the same time, I'm no-multilib, so all those --newuse and -rX-bump rebuilds really ARE useless rebuilds of the /exact/ same thing! While my system is fast enough it's not a big deal here, it's still a pain tracking all those -rX bumps to see what justifies the bump (at least I can tell simple USE flag changes on sight), and I hurt for those with slower systems! And wow, if you do go the global masking route, I seriously hope you have plenty of announcement before the big unmasking, with at probably 30 days warning and coverage on the web site, GMN, and news items, and possibly even a second news-item warning 3-5 days before it happens, since the global unmask will trigger about as big a universal rebuild as it gets, and those always bring quite a few user complaints. (Tho at least this one won't be breaking much of the system until it's done, unlike some of the big library upgrades of yore.) IOW, while that very likely would have been the better way to do it originally, I really don't know whether changing things up in mid-stream like this is going to result in more or less pain for users. Not being a stable-arch user nor being multilib, I've been spared much of the worry since on my systems it should "just work" either way, but honest question, how far /are/ we into this, and will the change now result in more work for more people (given that there's way more users than devs) than just continuing the current path, now that we're in the middle of things? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman