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 DC486138B43 for ; Wed, 20 Feb 2013 17:25:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3C64E21C004; Wed, 20 Feb 2013 17:25:25 +0000 (UTC) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 32473E0587 for ; Wed, 20 Feb 2013 17:25:23 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id m18so5192298vcm.36 for ; Wed, 20 Feb 2013 09:25:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:x-gm-message-state; bh=chGdfuIX6g06hu/SBaWmPG+u96SCBHNpIbL7eeCw1fY=; b=kP60AhOV6Lj1LcAugX9vLXlGoBI59L04YfZu/HswNVXe+/p8JsdRUn4bqWsPDuNDVg AkF8JWyGxwhh7Dvp7BoavjyC4Xf48bYsPPTkw/yenuJrV/8bGPzXfqma//qe2Q+S8aX2 GmO+xMmUU8pPzLE+jH6kKjI3AoRMCSgxAJwp5VT7u2kT8BRBhw+2EJybndPSXM/HX7iG 4tItH6piUM1ikXBb+5fYmTaFzJcaViAO7g2Hw3k3zBBFIOqeWkD16AMPF6Xh0WbQq/5V F1e9yH+b7Yb6ibfGEqvsWXAsx3GBMmYj/rqQPmhG2ZxZqW2DbZGDs9eoPVMol6cszBjS vXKg== 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.58.231.196 with SMTP id ti4mr27783553vec.25.1361381114721; Wed, 20 Feb 2013 09:25:14 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.220.108.77 with HTTP; Wed, 20 Feb 2013 09:25:14 -0800 (PST) X-Originating-IP: [75.147.136.182] In-Reply-To: References: <511F8D2E.1080006@flameeyes.eu> <511F9A9F.8040206@gentoo.org> <511F9ADE.2050503@flameeyes.eu> <20767.41371.270947.851486@a1i15.kph.uni-mainz.de> <5120654B.6050406@gentoo.org> <20768.43798.568305.561675@a1i15.kph.uni-mainz.de> <512389BF.9090504@gentoo.org> <5124CCE9.50203@flameeyes.eu> <20130220162802.30963.qmail@stuge.se> Date: Wed, 20 Feb 2013 09:25:14 -0800 X-Google-Sender-Auth: lsXNxNQI7pk4vkL1okdsKJ40uGo Message-ID: Subject: Re: [gentoo-dev] Re: linux-firmware From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkqHIEwDUWW2aqPIuZWq9KYE1g+bzolb8xUbN1x2ppTjHruhdPRuMZy+e0aYeyBAOSohBe/ X-Archives-Salt: 76b0e7e4-fcd3-4890-b6ea-4320299f3374 X-Archives-Hash: 2a06959468c1ad3b8299329801b20e09 On Wed, Feb 20, 2013 at 9:17 AM, Rich Freeman wrote: > On Wed, Feb 20, 2013 at 11:45 AM, Alec Warner wrote: >> On Wed, Feb 20, 2013 at 8:28 AM, Peter Stuge wrote: >>> >>> It makes no sense to make that unneccessarily difficult for users. >> >> I don't think fetch restriction is that annoying. You could argue that >> we do it debian / ubuntu style where the files are fetched in a >> postinstall, but I think that is sort of hacky myself. > > The concern wasn't with fetch restrictions so much as with masking. > Fetch restriction works if upstream provides a tarball but we can't > redistribute it. If upstream doesn't provide a tarball and we can't > redistribute anything, then a live scm ebuild is the only way to > deploy something, and current policy is that these must be masked. Not following you here. We cannot redistribute dev-java/sun-j2ee for instance. We don't mirror dev-java/sun-j2ee. We tell the user 'hey go download j2ee from Oracle and put it in $LOCATION. A live SCM ebuild is not the only way to deploy something. If the user has to go download a blob out of linux-firmware's gitweb because we feel we cannot legally distribute the firmware, then that is what they have to do. If the user has to go to the manufacturers website to get the firmware, then that is what they have to do. > > I do understand Diego's concerns with some edge cases, including the > tinderbox. Some kind of PROPERTIES=network solution might be the best > compromise. Until then masking things is better than dropping them. > It just doesn't seem ideal to have packages that are basically > permanently masked. Masking is usually a temporary solution for > testing or removal, or it can be applied to things like live ebuilds > which are moving targets that can never have QA. I think the fact > that we have to resort to masking in this case is more a reflection of > a limitation of portage, but saying so doesn't fix anything, so we'll > just have to live with it for now... > > Since this topic came up elsewhere in the thread it really isn't my > goal to cause inconvenience or debate things imply for their own sake. > I just would like to see things improve when it is possible, and > don't tend to censor my questions as a result. I don't really > disagree with the status quo simply because it is the status quo. I > think that is more selection bias - when I agree with the status quo > I'm less likely to post anything at all... > > Rich >