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 8D947138247 for ; Sat, 16 Nov 2013 20:24:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AC1C1E09DA; Sat, 16 Nov 2013 20:24:28 +0000 (UTC) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B57A1E0997 for ; Sat, 16 Nov 2013 20:24:27 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id s14so3110394qeb.19 for ; Sat, 16 Nov 2013 12:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=76d6MFZCX2Sp7dv3P/Kcm2BZiQjrxdyhpjdEl7WsCo8=; b=MTZ3sLaUlbI82pB3SZzJ4XDc8I5MHMmkQ+Aj+qkTj3XT9l/HUS9kzn7XvQWB/GgJ6L Hggspd5p3A15QY8qwbrRE4IksZ5mbKeQtdJ/PBU49UEqwMKLlnLEaKgdvTaI+P2eXgHE YWF7HbwiHMHh1rHivu02TeDNnxzSgmCCYM/BiJFBN0Di8W/4ROW4bvwzZ2qbV/33V+uk YVbWYso1iee89CwOKDkP+q7Ty8NQ0QEjk9cafYkMTc+VInbTMopKWtFuX5kSPn4w8eMB gPk1WP/IDZF5JtKA6TgVJJSJWY8j0BCRm+SNpULdqVsaVMoUWa7lekRf8Xd7VgrFeun6 aaYA== 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 X-Received: by 10.224.92.81 with SMTP id q17mr21496089qam.51.1384633466945; Sat, 16 Nov 2013 12:24:26 -0800 (PST) Received: by 10.140.39.197 with HTTP; Sat, 16 Nov 2013 12:24:26 -0800 (PST) In-Reply-To: References: <20131113151012.04145837@gentoo.org> <5283948F.1000409@gentoo.org> <52841023.9010208@gentoo.org> <20131114061328.09136f6f@gentoo.org> <20131115233934.7142bb04@gentoo.org> <1384590157.1308.13.camel@belkin5> Date: Sun, 17 Nov 2013 09:24:26 +1300 Message-ID: Subject: Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask From: Kent Fredric To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 3b6fd716-8c5f-48d6-8615-5b20a2bbd2f9 X-Archives-Hash: 4894eeb72ae1854352c1ab322e6b767c On 17 November 2013 01:39, Martin Vaeth wrote: > > This is really a severe restriction since the motivation > for installation can be very different for these variants. > For instance, for a native ffmpeg the user might want support > for a lot of codecs/devices while for the 32 bit variant > the user might want only support for those codecs/devices > which are needed for some special application. Nevertheless, > the same useflags mean that he has to build the same > (with all implied dependencies) also for 32 bit. Imo, thats a really good point. The convenience of having 1 ebuild support both 64bit and 32bit is sort of like a conflation of classes, because it behaves similar to having 2 ebuilds dove-tailed into one. Being able to specify different dependencies for different arches seems something that would be useful, especially in the following cases: Imagine, an ebuild provides 32bit and 64bit implementations. User only needs USE="a b c" for the 64bit version, but only USE="a" for the 32bit version. "c" however, on 32bit, needs a dependency to make it work on 32bit to smooth over a difference. But that dependency is unneeded on the 64bit version. Which means that USE="arch_32 arch_64 a b c" pulls in more dependencies than necessary to satisfy the users systems requirements. Just the overhead work to debride it and have a seperate package, or a seperate slot per ARCH_ABI might be more problem than its worth. So its just a question here of which tradeoffs are more acceptable for most of our audience. ( Yes, I'm referring to a similar question that came up the other day as to the advantages of having independent from and , and being able to have different USE flags for each was seen as a distinct advantage of the separation ) -- Kent