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 145BF138247 for ; Wed, 6 Nov 2013 18:22:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 65A4AE09D7; Wed, 6 Nov 2013 18:22:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 48207E09C6 for ; Wed, 6 Nov 2013 18:22:16 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id 2FE3633DACA for ; Wed, 6 Nov 2013 18:22:15 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id ar20so18504222iec.12 for ; Wed, 06 Nov 2013 10:22:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yW9F6z1hVA8sLSTO3a1lcLXzIm4quhU2XFTeVeH3ENw=; b=Q9B8muzWKnStCjhjz3IVY1+w52KvTuSNcaUTk52vNy0bRbklewAz0td2M+0HHIw3mn Aexh7LPFr5gicMgTKB7xfFQglN+cedRviQ68NqCy9Dk0mfOMteqWuVwH0/6f3aGgXW2W Gv84B3dBrksglYCwVGW9D/qzt3zj+m4f6IDxxVnIFSqdTPgqbG4xiqFGpYVgTEEhLbjF OwxWebTkhPp93DO60M46bZjdccbY6QiOU7Omll6qSJv3fhpKlmURaoNzQ5vAIdcHbklK O+Q1LSNd8066VbnwKBIUf4o6CrKGRHSklg3YQHpYaJrB5E4pYj31B3cjrufE98UAsQjh P8YQ== 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.50.11.11 with SMTP id m11mr21078852igb.47.1383762133250; Wed, 06 Nov 2013 10:22:13 -0800 (PST) Received: by 10.64.139.5 with HTTP; Wed, 6 Nov 2013 10:22:13 -0800 (PST) In-Reply-To: <527A84A3.7070607@gentoo.org> References: <527A5D22.10009@gentoo.org> <1383752934.23332.4.camel@localhost> <20131106185611.01c6f6ac@gentoo.org> <527A84A3.7070607@gentoo.org> Date: Wed, 6 Nov 2013 13:22:13 -0500 Message-ID: Subject: Re: [gentoo-dev] Policy-level discussion for minimum versions on dependencies From: Mike Gilbert To: Gentoo Dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 1a835717-b421-452e-87f5-385eebc3692e X-Archives-Hash: 2a2c7feb259e55101804b46b24c2a2f4 On Wed, Nov 6, 2013 at 1:04 PM, Ian Stakenvicius wrote: > On 06/11/13 12:56 PM, yac wrote: >> On Wed, 06 Nov 2013 16:48:54 +0100 Alexis Ballier >> wrote: >> >>> On Wed, 2013-11-06 at 10:15 -0500, Ian Stakenvicius wrote: >>>> However, it's been a long-standing general practise that if >>>> there are no deps in the tree older than what is necessary for >>>> a package, that package doesn't need to have a minimum version >>>> on the dependency atom. As such, issues similar to this are >>>> probably lying in wait all other the place in the tree. >>> >>> this is a common misconception: ebuilds must have min. deps >>> matching their requirements (exactly because of this problem) >>> >>> it can be fixed on the user side by 'emerge -uDN world' meanwhile >>> but this doesn't mean the ebuild doesn't have a bug, even if >>> minor >>> >>> Alexis. >> >> When I started contributing via sunrise, I've been adding the >> minimal versions of dependencies as declared by upstream but I met >> with very strict enforcement of the policy to not specify minimal >> version if all the ones in current tree satisfies. >> >> Is it documented somewhere or is it just unwritten consensus? >> >> What I see is only Ebuild Policy [1e] which doesn't deal with >> this. >> >> .. [1e] >> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1 >> >> > I searched as well, and couldn't find anything documented one way or > the other, either. I concluded that it's unwritten consensus. > > That's the main reason I wanted to start this discussion -- to > effectively start documenting it and get dev's all on the same page. > To be honest I think it should be policy or at least a written-down > guideline, that dev's should do this within reason -- if an > older-than-minimum version of something has been in the tree within > the past year. Gone for more than a year should be safe, I expect. > I don't think a time limit is necessary here. If there is an identified incompatibility, we should update DEPEND. Note that I do not expect devs to go out of their way to test for the oldest supported version of a dependency; they just shouldn't close bugs as INVALID of someone else has done the work.