From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N7HTD-0001ei-4G for garchives@archives.gentoo.org; Sun, 08 Nov 2009 23:46:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1214FE0D2D; Sun, 8 Nov 2009 23:46:54 +0000 (UTC) Received: from dsrg.mff.cuni.cz (dsrg.mff.cuni.cz [195.113.20.55]) by pigeon.gentoo.org (Postfix) with ESMTP id CC716E0D2D for ; Sun, 8 Nov 2009 23:46:53 +0000 (UTC) Received: from r9.net.upc.cz ([62.24.83.9] helo=[192.168.1.112]) by dsrg.mff.cuni.cz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1N7HT9-0003vo-Up for gentoo-dev@lists.gentoo.org; Mon, 09 Nov 2009 00:46:53 +0100 Message-ID: <4AF75860.30300@gentoo.org> Date: Mon, 09 Nov 2009 00:46:40 +0100 From: Vlastimil Babka User-Agent: Thunderbird 2.0.0.23 (X11/20090909) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: QA: package.mask policies References: <200911071824.16651.scarabeus@gentoo.org> <20091107180322.GA23301@linux1> <20091107193312.5df04226@gentoo.org> <8b4c83ad0911071608n7ebc31dcy6e7eb1d9470b3067@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 X-Spam-Level: ---- X-Archives-Salt: e166f98b-7d9c-4a9f-89d4-caaaba161e48 X-Archives-Hash: c97ab8a3465882460e3d9deee2ace15a Duncan wrote: > In theory that's what those stupid version string thingys are for, but > it's soooo much easier just to forget one! =:^[ > > Maybe something about this should go in the handbook -- a suggestion that > if one is going to use a package.unmask entry, that they copy the > package.mask entry over, thus at least letting the devs minimize the > version spread damage with their package.mask entries. That's what I've > started doing, and it works surprisingly well, as I have right there the > comment on why it was masked (and add a comment on why I'm unmasking, > when I think I might wonder, later), and it's the exact same versions the > devs masked in the first place, so I don't have to worry so much about > unintended version spread -- at least as long as the devs doing the > masking worried about it then. =:^) > > What do you devs think? Would that be a practical hint for the > handbook? Would it be helpful in allowing /you/ to control the version > spread of the unmask, by consequence of your control of the version > spread on the mask in the first place? Hi, handbook is one thing, but maybe portage could make it more prominent when it displays the packages to be merged, so that the users hopefuly notice? - visibly distinguish (red color and stuff?) packages that are to be installed thanks to package.unmask or ** keyword - print extra warnings about those entries in package.unmask and ** keywords that are not version restricted, if they contain the packages to be merged. This could follow the suggestion above - aside from the distinguished packages, below the list and above the yes/no (if --ask is used) there would be "Warning: the following packages have broad unmasks, you sure you want these versions?" and the list. Vlastimil