From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-63779-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 9F46E13827E
for <garchives@archives.gentoo.org>; Sun, 8 Dec 2013 20:17:53 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id C53D1E09EE;
Sun, 8 Dec 2013 20:17:47 +0000 (UTC)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id DEE8CE09CD
for <gentoo-dev@lists.gentoo.org>; Sun, 8 Dec 2013 20:17:46 +0000 (UTC)
Received: by mail-ve0-f173.google.com with SMTP id oz11so2958570veb.32
for <gentoo-dev@lists.gentoo.org>; Sun, 08 Dec 2013 12:17:46 -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:content-type;
bh=/qWgxFvj3a8e1NwLkrCKE8NqA85+t0iwCAxujcEWq5g=;
b=AryOd3RuIlypzJgBTj/f6ufFVDXC/vtwPg6zV+vAZ2LgvrnKZIUro+pgyQHE4x1saC
mK+h2HdLkMgy5BlWlxBdBRYHorq88Sx/TYtKcndRBVxEnXASMvLW4LwlthlTRt0Fm9wZ
k5/SJneigWSTOuYNBRkPP2pzgiH/1eKR0PtSOwfC3OFoUeahRLMwjP2gHQifuZeaItxZ
qdTl8Vgc9mL1cmkmv57lXGSeMSyOgkIUi2Or7FNtPbEQ42qwxoqcW4nSecw2s4ubYctH
Y73G14yAlS1ocqTjPi38iV7YFXVJLw4nKPEVm77707l0XlYEcO9YL+lePxLt3Q4cA/N5
47YA==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.220.253.66 with SMTP id mz2mr9627681vcb.10.1386533866177;
Sun, 08 Dec 2013 12:17:46 -0800 (PST)
Sender: freemanrich@gmail.com
Received: by 10.52.112.99 with HTTP; Sun, 8 Dec 2013 12:17:46 -0800 (PST)
In-Reply-To: <21156.53244.886349.924357@a1i15.kph.uni-mainz.de>
References: <20131208175612.2b8c7e38@TOMWIJ-GENTOO>
<201312081819.40449.dilfridge@gentoo.org>
<21156.50471.613516.395616@a1i15.kph.uni-mainz.de>
<CAGfcS_=Y5hwaVw60cX==XxYPu0Z6wK5TOJYQrkc9Att83fqiHg@mail.gmail.com>
<21156.53244.886349.924357@a1i15.kph.uni-mainz.de>
Date: Sun, 8 Dec 2013 15:17:46 -0500
X-Google-Sender-Auth: QBGAmRo4evsq0zfmqvMNirK72_o
Message-ID: <CAGfcS_nwTc3AYPQ8cmGR=xQCtfQfru2NhBC8Wtpvui-BARqB5A@mail.gmail.com>
Subject: Re: [gentoo-dev] Dependencies default to accept any slot value
acceptable (:*), can we default to :0 instead?
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: e26c8f8f-ce15-4851-824d-f9e6a0ca28ce
X-Archives-Hash: efd57d91a920f84244db4003ec0f7992
On Sun, Dec 8, 2013 at 3:01 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Our rules of slot/subslot dependencies and slot operators are just
> complicated enough, so I really would dislike complicating them even
> more by having an EAPI dependent default. In addition, from a package
> manager view there is nothing special at all about slot 0, so there's
> no reason to prefer it over other values.
I can see that argument, but what then? What should be the best
practice for a maintainer?
A new slot of a package (which doesn't exist today) may or may not
work with any ebuild in the system. Should it be considered a best
practice then to specify || deps with all slots that are known to work
in the tree? Or should we just trust to luck and consider it
acceptable for maintainers to add new slots of commonly-used libs and
users and downstream maintainers can deal with the resulting breakage?
Library maintainers don't seem to like dealing with that, so they just
stick new slots in an entirely new package, and then we end up with
all the || dependencies anyway and we make no use of the nice slot
syntax because it is prone to breakage.
It seems like the current way we handle slots for dependencies works
just fine until somebody actually tries to introduce a new slot for a
package, and then a whole pile of assumptions comes crashing down.
Rich