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 5CBD41381F3 for ; Fri, 26 Apr 2013 18:44:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 644CCE0C19; Fri, 26 Apr 2013 18:44:39 +0000 (UTC) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 78546E0BE5 for ; Fri, 26 Apr 2013 18:44:38 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id kw10so4092417vcb.33 for ; Fri, 26 Apr 2013 11:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=2EZxBKxBosh2UoZbGlqSVcUImYgDk3WPIemtRwam7v0=; b=TgcoxhjaWF44WKXtr3YIpmJIdnhrpfSB1/pxGg0aabSr3SUW1whSPg9/FZpQwFYo2H lWCoY1he/cW+FN2xdQx/sInx2igEfrBhVPc9el5SBOm73hK7HSP59LiLTOk36fpZDCNv /SiPxCbRtVpOk6VO6ufRtO4EMUL9TEPdPE596JESoUxY2kubg292lpUuU5U/WVL1GeZi p2VjKNDJcUzzgJBLjFTbKPYwN/Qy3rpySmSYnC1PjkJf8k2DJ+kGQ6DUL1vFMC8UGUrV bcHUV5x9+e4b0CVjQcJyiQmz0f0oHyKEljTXdP+bCzD8BH+i8oC7EzQvWHmleoSOiyn4 /o0A== 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.52.93.233 with SMTP id cx9mr8138304vdb.112.1367001877613; Fri, 26 Apr 2013 11:44:37 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.168.4 with HTTP; Fri, 26 Apr 2013 11:44:37 -0700 (PDT) In-Reply-To: <517AC7C8.408@gentoo.org> References: <20858.42422.774640.252393@a1i15.kph.uni-mainz.de> <517AA97D.8040402@gentoo.org> <20130426185621.68dbd58a@marga.jer-c2.orkz.net> <517AB5DF.9090601@gentoo.org> <20130426191536.0c8eaf14@marga.jer-c2.orkz.net> <517AC7C8.408@gentoo.org> Date: Fri, 26 Apr 2013 14:44:37 -0400 X-Google-Sender-Auth: yszVjw1TyXWYwkpVRAjnoGWGuRU Message-ID: Subject: Re: [gentoo-dev] Should mirror restriction imply bindist restriction? From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 4f309543-0c37-486c-9651-0a98dead3bbb X-Archives-Hash: 29b3948e58e6bb11405e6420c860a5d6 On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina wrote: > The user is distinguishing right from wrong by setting things like > USE=bindist, portage simply doesn't seem to be respecting that in the > case of RESTRICT=bindist. I think what is missing is a clear set of definitions. USE=-bindist means build a package that the maintainer thinks isn't legal to distribute under some set of circumstances (which might or might not be the user's circumstances). RESTRICT=bindist in an ebuild means what? Let's look at the devmanual: RESTRICT - A space-delimited list of portage features to restrict. Valid values are fetch, mirror, strip, testand userpriv. See man 5 ebuild for details. man 5 ebuild: bindist - Distribution of built packages is restricted. And how does a user tell portage whether they intend to redistribute something in the first place? The fact that an ebuild sets RESTRICT=bindist does not have anything to do with whether it will in fact be redistributed. It sounds like we would need a FEATURES=bindist to go along with it. Oh, and it sounds like RESTRICT=bindist often should be conditional based on USE=-bindist, but you can't set RESTRICT conditionally, so that won't work. Also, isn't all of this somewhat redundant with ACCEPT_LICENSE? It is the license that allows you to redistribute something in the first place, though with some licenses it might be conditional upon how the package is built/branded. The last thing we need on any of this stuff is a hard error. What is needed first is for those who care about such things to cleanly specify a sane set of definitions and behavior. Rich