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 3029A138247 for ; Wed, 6 Nov 2013 16:15:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C3FC9E09B3; Wed, 6 Nov 2013 16:15:48 +0000 (UTC) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BC793E0969 for ; Wed, 6 Nov 2013 16:15:46 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id b13so5052359wgh.34 for ; Wed, 06 Nov 2013 08:15:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SjWPJ6uliRstXwMeBrPWig8O6V7iwkzZ020nZbJevdg=; b=jSvurgjcyuq2uCXP2ij7ZtU2Adv1j1H1rRQJArcBgw0hIjAKqonmxTi0APQr+/4rjt WvluBag+nHtYitOqqreN+pvSxAn4dLZjsupWQzvaqnNyr5d7FUeNNHXlk9prAbXtQIrc k7A2LMkXuv8fqT5+W3d++CNUaxqI/+xGYhAmjSUO7gncSJiz1hC+jcJO+fDJ1im5isEI 00/pzKQBmOj0yFED2WAajs67O/DffFS7S7/+Sj8PWwBjSzugsZE+HoSILroue/xw1Odo 126vRm2sOMfLlRhkGEtkslvfLXHwZ4Ctcgz6we96bBmacMUdy4m9HqH2NbvLBfZQHqIf UMWA== X-Received: by 10.194.175.66 with SMTP id by2mr2264921wjc.59.1383754545571; Wed, 06 Nov 2013 08:15:45 -0800 (PST) Received: from [172.20.0.40] (196-210-126-109.dynamic.isadsl.co.za. [196.210.126.109]) by mx.google.com with ESMTPSA id hv5sm26128545wib.2.2013.11.06.08.15.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 08:15:45 -0800 (PST) Message-ID: <527A6B1C.8070501@gmail.com> Date: Wed, 06 Nov 2013 18:15:24 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.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] Policy-level discussion for minimum versions on dependencies References: <527A5D22.10009@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: fdba82ee-47d8-4d0b-b62d-84e027bbfc3c X-Archives-Hash: 7209a2156bc8825e6c7f17b4db96bef8 On 06/11/2013 17:26, Kent Fredric wrote: > > On 7 November 2013 04:15, Ian Stakenvicius > wrote: > > > The bug that was filed, is that a user didn't do a full emerge -uDN > @world prior to emerging (upgrading?) firefox, and they had icu-49 > already installed. Because the firefox dep didn't have a minimum > version, portage didn't see upgrading icu as a requirement before > firefox emerged. > > > Theres another scenario not listed here which can still happen: > > The end user has a copy of icu-49.ebuild somewhere in their portage > layout still. > > Either this is due to a published overlay containing it, or them locally > maintaining their own private overlay. > > The "update world" thing *may* still work in such a circumstance, but > you'd have to change the policy to say "Update to a something that is in > ::gentoo before merging packages from ::gentoo", which is getting a bit > logically messy. > > Even then, it may not be apparent that there is a problem, for instance, > if they have the overlay in place, *AND* they've locally masked newer > versions of icu, for some reason ( perhaps they have 3rd party software > they're locally maintaining that requires an older version of icu ). > > Here, the *only* sane approach is for firefox to declare it needs a > certain version of icu as a minimum, regardless of what is, and what > isn't visible in tree, so that the end user at very least gets told > "firefox needs this", and its then their responsibility to sort out the > problem if they've caused one. I agree with this sentiment. It's always been my view that the needs of a package are driven by the package itself, not by the tree. Rationale: A package will build and run as long as it's own requirements are met regardless of what the tree states. We have layman overlays and user's own overlays. Whilst these are not 100% supported by Gentoo they are not banned either. They are also not "barely tolerated", it's more a case of overlays are not a problem and users are welcome to use them as long as they don't conflict with or break the tree for that user. This needn't be onerous. Presumably ebuild maintainers read the README and Changelog, these often state the versions of deps the package supports. Take that information and put it in the ebuild. Maintainers are under no obligation to provide the absolute minimum version of a dep, only at least one that will work. If the user decides to make other versions available to his system by whatever means, then portage can deal with it by and large transparently. -- Alan McKinnon alan.mckinnon@gmail.com