From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-160084-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 2CF55138A1A
for <garchives@archives.gentoo.org>; Sun, 23 Nov 2014 17:34:00 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D2D64E0885;
Sun, 23 Nov 2014 17:33:54 +0000 (UTC)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 7FDE1E0831
for <gentoo-user@lists.gentoo.org>; Sun, 23 Nov 2014 17:33:53 +0000 (UTC)
Received: by mail-wg0-f52.google.com with SMTP id a1so10701875wgh.25
for <gentoo-user@lists.gentoo.org>; Sun, 23 Nov 2014 09:33:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=sender:date:from:to:cc:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
bh=yh7vddjfiZOs1ZN4Z+rz7lW2FRjh7zfNXP3uYgPAZw0=;
b=YRmtvyFUADtPgeCEiqx3oMxdnQIxw8rProUiEyOGOFO2scNiOhXFgj4DQon6PsIxNQ
9krFTsAkiDDrYBDw4yGPa6yyp53HCLU0HaIEjivgYRn8fPOGnD8u9H5icJBt2M4Qcqg/
xXeKeU2/rh13Gl+4ROdvVRZbxvKnQBPHy9hdGYh0lVdGfgIS5+D0ZG6omkgt4spMmMI+
nrnm9eEjVA4WO86EZ4/ws88QW7UTbgZob/8gwgGOx2nI5NLuAWbQ5R1akW/N/J555NW4
rQwCUCgG4HJ3bKgAyy2qCmt3aDc79Zwm/cLi7Pe/xjqwao0x84cRGPEgC2/1JBsHNuUo
+pHQ==
X-Received: by 10.180.84.132 with SMTP id z4mr14454171wiy.55.1416764032228;
Sun, 23 Nov 2014 09:33:52 -0800 (PST)
Received: from vidovic.ultras.lan (50.132.84.79.rev.sfr.net. [79.84.132.50])
by mx.google.com with ESMTPSA id bj7sm17303582wjc.33.2014.11.23.09.33.50
for <multiple recipients>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 23 Nov 2014 09:33:51 -0800 (PST)
Sender: Nicolas Sebrecht <ni.s.nis33@gmail.com>
Date: Sun, 23 Nov 2014 18:33:48 +0100
From: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
To: gentoo-user@lists.gentoo.org
Cc: Nicolas Sebrecht <nicolas.s-dev@laposte.net>
Subject: [gentoo-user] Re: Gentoo's future directtion ?
Message-ID: <20141123173348.GB2139@vidovic.ultras.lan>
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>
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
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5471FDE1.2040108@googlemail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Archives-Salt: 1a7fac13-c9d6-46da-b9cc-c33b8eecc2be
X-Archives-Hash: 68bfb588831b16431967803414433f6c
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.
--
Nicolas Sebrecht