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 ADBC713877A for ; Fri, 8 Aug 2014 19:48:11 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 40F82E0952; Fri, 8 Aug 2014 19:48:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 56C62E0893 for ; Fri, 8 Aug 2014 19:48:06 +0000 (UTC) Received: from [192.168.1.130] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id 29BF3340331 for ; Fri, 8 Aug 2014 19:48:05 +0000 (UTC) Message-ID: <53E5296D.30200@gentoo.org> Date: Fri, 08 Aug 2014 15:47:57 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] minimalistic emerge References: <53e4ccbd.c2b4700a.3bec.2414@mx.google.com> <20140808193433.25388.qmail@stuge.se> In-Reply-To: <20140808193433.25388.qmail@stuge.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: b8a627b2-7892-42ed-92e4-99ee1d61e936 X-Archives-Hash: 066a9f10cc544861031a86f34df09f3e -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/08/14 03:34 PM, Peter Stuge wrote: > Kent Fredric wrote: >> dependencies are forward specifications from upstream telling us >> what their software needs to function properly. > > Unfortunately that's not the full story. :\ > > ebuilds often (for me) have artificial dependencies, when the > actual version required is too old to be in the tree, but maybe not > too old to be installed on an existing system. > > I think it's bad policy to lie about dependencies in ebuilds for > the sole reason of only ever depending on versions which actually > exist in the same snapshot. It's a too simplistic model of > reality. > For the most part I don't think that happens very often; usually if all stable versions of a dependency can satisfy a package's needs then there isn't any minimum version specification (or the minimum version specification hasn't actually been updated in an ebuild's *DEPEND, despite the older versions having been removed). The main exception to this is the work done related to gx86-multilib (as for obvious reasons the multilib ebuilds are needed to supply multilib dependencies), and the refactoring that mgorny did a few weeks back to fix the EAPI<5 USE_EXPAND+IUSE_IMPLICIT undefined behaviour issue. That said, even if dependency atoms allow the older, no-longer-in-tree versions to satisfy a package's needs, as I said earlier I don't think any dev has the time and resources to test against anything older than latest-stable, and definitely not anything that's no longer in the tree. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlPlKW0ACgkQ2ugaI38ACPDAewD/ebk6WQa4pA4VJQkpiXf2Ch/R uGz0HRy6/Y17eSxDL3wA/2gD8ciNsVWkIV6/kLGwwVXGItLL07A3OXITGLE1U8+N =EBWi -----END PGP SIGNATURE-----