From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-160088-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 C01CC138A1A
	for <garchives@archives.gentoo.org>; Sun, 23 Nov 2014 18:25:41 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id B8C2CE0A4F;
	Sun, 23 Nov 2014 18:25:30 +0000 (UTC)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 5299CE0A04
	for <gentoo-user@lists.gentoo.org>; Sun, 23 Nov 2014 18:25:29 +0000 (UTC)
Received: by mail-wi0-f170.google.com with SMTP id bs8so7150337wib.5
        for <gentoo-user@lists.gentoo.org>; Sun, 23 Nov 2014 10:25:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlemail.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        bh=rzFFFbd3wQmmjZjCCAO13jW3UsP1Hvdz9dEtPlqi7ds=;
        b=FTEKe4EegRrNR0AiDYUtEqXNtvDRoMK/zZBDrIbQqJI3VJwXVijds2hx9AT+m52shj
         B5SCJecLJ3KorB5lGB7DJoB9DWcdLmKmi4BzKyqvmBc8EFrbqAGrtKqJP1lBRgVbDoK5
         I7LCIcQISXy93n6arQFZkEcndo47olxoN2uN1vnQ2C2y/Z3ZQsJx4D1cZnewXONplFiV
         gtRlv8YyxEw7UhDvWbnoR6e4Mk1krG9KAXdho0uz22te99ov06UkYIMGdTM1ajSw1Tq4
         VrE4fziJEh6rUHZlS3tYIyH8xMWMC+jrbSY6o2IGQ441Vm/7bUxbYWhwUgnjXYKOrY31
         65XA==
X-Received: by 10.180.11.8 with SMTP id m8mr14589723wib.11.1416767128066;
        Sun, 23 Nov 2014 10:25:28 -0800 (PST)
Received: from [192.168.178.21] (p4FC12258.dip0.t-ipconnect.de. [79.193.34.88])
        by mx.google.com with ESMTPSA id l3sm9704609wje.12.2014.11.23.10.25.27
        for <gentoo-user@lists.gentoo.org>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Sun, 23 Nov 2014 10:25:27 -0800 (PST)
Message-ID: <54722696.2030803@googlemail.com>
Date: Sun, 23 Nov 2014 19:25:26 +0100
From: Volker Armin Hemmann <volkerarmin@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: Gentoo's future directtion ?
References: <op5uW-6vB-25@gated-at.bofh.it> <op5uW-6vB-15@gated-at.bofh.it> <opcd3-84i-7@gated-at.bofh.it> <5470D229.7000806@tampabay.rr.com> <5470DBF5.1060304@gentoo.org> <CAGfcS_=we+kk4i+tV6jwVi+K=6GNe3-N2N8baigDY5ndrbp_5w@mail.gmail.com> <547111B5.2030909@gentoo.org> <CAGfcS_=0rhQB4aMq5ajvS-R0rqGtVEY_ZX-UE4Ckp06+PcaR1w@mail.gmail.com> <20141123151825.GA2139@vidovic.ultras.lan> <5471FDE1.2040108@googlemail.com> <20141123173348.GB2139@vidovic.ultras.lan>
In-Reply-To: <20141123173348.GB2139@vidovic.ultras.lan>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Archives-Salt: 81093ab2-74ca-4ba4-b316-bf3b7a827392
X-Archives-Hash: 35efc8a0d83fcc1c88336fe54c133a1d

Am 23.11.2014 um 18:33 schrieb Nicolas Sebrecht:
> On Sun, Nov 23, 2014 at 04:31:45PM +0100, Volker Armin Hemmann wrote:
>
>> am I the only one who thinks that this way leads to madness?
>>
>> Version conflicts are bad enough.
> First, version conflicts have their roots in the support for versions of
> libraries in softwares. This is the best place to fix that when
> possible.
>
> When it comes to ebuilds maintainers, version conflicts are about all
> about DECLARATIONS. If software A need Y-v1..12, we should have a way
> for the maintainers to declare that A relies on Y-v1..12 and let the
> dependency softwares to the hard job and admin/users handle them the way
> they want.
> Today, this is badly managed with implicit expectations everywhere.
>
> Also, there are ways to overcome version conflicts. Slots are one of
> them.
>
>>                                   No multiply that with a bunch of
>> overlays, all having their own libXY with just some tiny, tiny
>> differences, and another bunch of overlays who want libXY from certain
>> others....
> That's a reason why I said that overlays are a poor kind of pointers.
>
> For overlay maintainers today, if the main portage tree does not offer
> what they expect, the only option they have is to rewrite their own
> "static" dependency tree with their own ebuilds. That sucks.
>
> Portage should support a way to expose ALL the conditions for a software
> to work and update installed libraries to match the requirements.
>

and you want portage to finish on this site of eternity when looking for
dependency resolution?