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 1266B13877A for ; Sat, 14 Jun 2014 16:23:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65A2CE0B14; Sat, 14 Jun 2014 16:23:48 +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 863B9E0B10 for ; Sat, 14 Jun 2014 16:23:47 +0000 (UTC) Received: from 127.0.0.1 (vm2.randomserver.org [178.63.169.84]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 24E6033FE88 for ; Sat, 14 Jun 2014 16:23:44 +0000 (UTC) Message-ID: <539C770C.4040507@gentoo.org> Date: Sat, 14 Jun 2014 16:23:40 +0000 From: hasufell 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] Subslots: should they be bumped like SONAME or on any ABI changes? References: <20140614164151.45afb5ca@pomiot.lan> <539C72B1.8070205@gentoo.org> In-Reply-To: <539C72B1.8070205@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3f8a8bf0-85a2-49d6-bfae-717175c13f4d X-Archives-Hash: 70a58ea8896d341fc5cdc2d3a4991f72 Ian Stakenvicius: > > > I vote that as primary policy/general practice, it only be bumped for > (2) -- the primary purpose of subslot rebuilds is to allow portage to > figure out the deptree order when a dependency upgrade is going to > break a package that may or may not be emerged later. "break" is the > key term here. If users want to re-emerge the rdeps of a package on > upgrade they can certainly do so, but I don't see this as something we > want to force on everybody just because we can... > ++