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 0751213827E for ; Mon, 9 Dec 2013 16:06:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5D978E0C09; Mon, 9 Dec 2013 16:06:07 +0000 (UTC) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6D158E0C04 for ; Mon, 9 Dec 2013 16:06:06 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id g10so675374vbg.13 for ; Mon, 09 Dec 2013 08:06:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Sue7aKQuM4jwDw5ssdEmNSH/7C27E9acTGVQhaFINoE=; b=SdpoeQddEhFE6z2IxtnoESCd966y3RZ1WMgh69gq/cWaqFX41o348ZPKBls4Yzkba9 M++q0rqlo9e2iT7J5vChcQJb3kMQfZt2avEGEVmjHCBybXPzJlkXmAmdo5U0BhRvwGWK NPgaHsWfyuhJrPIyfdozEsbDaWy/6eqepJ0jwRqycRQd4DAGrLgTcc3rlAax6QEEzDNg pOijJfiZNcunZIrR6ceEAaElHTtY2CxWvS4lHMfRSI5+fuK5oQxvBIXhdgxjoEayiC+d nF5Rt8yjL/Nm6qKAXqf9WQCzNabAUtu8nLVROmrb9eceDLdZe0Edp+JG7o4UNl+r4KM7 ZvDw== 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.162.168 with SMTP id yb8mr9462842vdb.8.1386605165631; Mon, 09 Dec 2013 08:06:05 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.52.112.99 with HTTP; Mon, 9 Dec 2013 08:06:05 -0800 (PST) In-Reply-To: <20131209115527.4ef48b36@TOMWIJ-GENTOO> References: <20131208175438.100112a0@TOMWIJ-GENTOO> <52A5689F.1040402@gentoo.org> <20131209115527.4ef48b36@TOMWIJ-GENTOO> Date: Mon, 9 Dec 2013 11:06:05 -0500 X-Google-Sender-Auth: T1udOFAHV8CZKtvqZQt01IElFXI Message-ID: Subject: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? From: Rich Freeman To: gentoo-dev Cc: Sergey Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: aad24355-aa26-4e66-ab56-ea350fb33c60 X-Archives-Hash: 9d680baefe1e6455639e12189363851b On Mon, Dec 9, 2013 at 5:55 AM, Tom Wijsman wrote: > For the dependency syntax, having :* as a default breaks things or > causes a lot of work. If explicit slots (or :0) were the default, it > works and you spare out dealing with lots of reverse dependencies when > you introduce a new slot. I was giving this some more thought and here is another way of looking at t= his. Let A be the set of all situations where it makes sense to create a new slot for a package that has reverse dependencies. Let B be the subset of A where it makes sense for those reverse dependencies to automatically use the new slot without any intervention by the reverse dep maintainers. If |B| >> |A \ B| then the current default makes sense. (That is, if the number of elements in B is much larger than the number of elements in A that aren't in B.) If |B| << |A \ B| then it would make sense to require all slot dependencies to be explicit, and the ":*" dependency to be frowned upon in general. I think that the above just makes sense if you think about it, so I'll use that as my initial premise for what follows. By all means challenge this. So, what I'm going to do now is speculate that B =3D =E2=88=85 (that is B i= s the empty set). Therefore, it makes sense to get rid of the current default and require all slot deps to be explicit. If you think that B isn't the empty set, it is trivial for you to demonstrate that this is the case. Simply give me a single example of a situation where: 1. It makes sense for a dep to use a new slot. 2. It makes sense for all of its reverse deps to automatically use the new slot without any further intervention by the individual reverse dep maintainers. I can't think of any, and I'm all ears if somebody else can. It seems to me that our current default optimizes for a situation that is dubious from a QA standpoint. Its main virtue is that you don't have to go look up what the current slot is for slot-less packages, but honestly if you just stuck a :0 on every line of your ebuild chances are it would work on the first install and at least the behavior would be consistent for anybody else who uses it. Rich