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 6A43C138247 for ; Tue, 5 Nov 2013 19:59:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 59CE0E0AEE; Tue, 5 Nov 2013 19:59:24 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 30BE5E0930 for ; Tue, 5 Nov 2013 19:59:22 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id f4so2658375wiw.16 for ; Tue, 05 Nov 2013 11:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=H8Hxp1DnXOd4bZM46P37HhftjUpNwVuWx3PjHeK8kRs=; b=kSPMvHbnIrioqIZRjUF5GRkUXKaAmXPWbjE+z/uMdIn3YH2NxjsLjYKGwmZi6VQOfe wnCv+fChglxmIoJN9qBt7Js07GEWLs+MjYBqfFKiL8gbKg5jVz5S0oOdpB90TU3SMFea +WzR5RZU03r0Or3MAaTcbgxaablYSKN5pNz7F5xCTWhMh+qB0GjBN+kL0LX0fgnIyAZ5 MN2Hozc27fySpRa7k4tKKnYpaTh70SNStMU2RYa6XMozpe9ovM+7H4bRzF+Btb5j2sjd B3aH1DnVubK6jsjomsjhshmqLrMnxgXOr78dBIfHQBbA3zM6hupssmIuNuRao0Q9H0tB CNgA== X-Received: by 10.180.99.99 with SMTP id ep3mr18142769wib.11.1383681561671; Tue, 05 Nov 2013 11:59:21 -0800 (PST) Received: from [172.20.0.40] (196-210-126-109.dynamic.isadsl.co.za. [196.210.126.109]) by mx.google.com with ESMTPSA id y20sm17098759wib.0.2013.11.05.11.59.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 11:59:21 -0800 (PST) Message-ID: <52794E07.80008@gmail.com> Date: Tue, 05 Nov 2013 21:59:03 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: do subslots improve user-experience? References: <5274EA64.6000404@gentoo.org> <5274FB18.1070102@gmail.com> <5276AA1D.2020907@gmail.com> <5278C523.8070906@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 74aa98c8-fed4-48ed-acc9-b427827ea7c8 X-Archives-Hash: 962760e223c128d54666a5ceee60f42f On 05/11/2013 20:06, Martin Vaeth wrote: >> I predict once a week fallout from sub-slots induced bugs that was >> > intended to fix once a year problem. > Let's see: Forgetting to bump a subslot means that the purpose of > subslots for that package fails. A problem, but not worse than > without subslots. Bumping unnecessarily means that perhaps some > packages are rebuilt unnecessarily. Also not something dramatic. > Even if this *should* happen once a week (which I strongly doubt; > more realistic is once in a few months) nothing dramatic happens. > > Why am I still feeling that I am not being understood correctly? You don't have to keep explaining subslots to me, I understand how they work and what they aim to accomplish: DEPEND is a forward dependency and cannot deal with reverse dependencies. Subslots provide the information to portage to be able to deal with reverse dependencies when generating the dep graph. It does not do it by interrogating the live filesystem or by discovery, it does it by using metadata added to the ebuild by a human. I know that if subslots are correctly defined throughout the tree, rebuilds will happen during the emerge, and a later @preserved-rebuild or revdep-rebuild will in all likelihood return null. I have no problem with any of that, so there's no need to justify those claims further. What I have maintained all along is that I don't see the solution as tested to be production-ready and no-one has definitively stated what can happen when a junior dev gets it spectacularly wrong. This may or may not turn out to be a real problem in real life , but it is an anticipated one that deserves an answer. Keep in mind the real world nature of what a bug usually turns out to be: something the dev did not anticipate (actual code flaws being comparatively rare) -- Alan McKinnon alan.mckinnon@gmail.com