From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Lf2qr-0000Wc-JP for garchives@archives.gentoo.org; Thu, 05 Mar 2009 01:58:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 80740E0320; Thu, 5 Mar 2009 01:58:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5ED8BE0320 for ; Thu, 5 Mar 2009 01:58:20 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id BF277643B9 for ; Thu, 5 Mar 2009 01:58:19 +0000 (UTC) Message-ID: <49AF31C3.6090000@gentoo.org> Date: Wed, 04 Mar 2009 17:58:27 -0800 From: Zac Medico User-Agent: Thunderbird 2.0.0.19 (X11/20081209) 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] Repository stacking and complementary overlays References: <1235702483.8324.38.camel@localhost> <20090302164807.6324266c@snowcone> <49AF2CE8.3020508@gentoo.org> In-Reply-To: <49AF2CE8.3020508@gentoo.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 2ee189ef-3a11-4f91-8228-8bcbdf4f6b3b X-Archives-Hash: f8fdde4605043cbe6c28bde74db1c8b7 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Manuel B. S. Vicetto wrote: > This seems desirable and reasonable. > As I replied to this subject earlier regarding KDE, let me complement > that information. In the case of the KDE team, we keep work on a release > all in the same place, so we don't need to unmask some KDE packages in > tree for those using the overlay. However, we some times have deps on > packages from other teams and or in other overlays, so I hope the repo > deps would help here (not to unmask those packages, if they're masked, > but to add a dep on a particular repo and allowing the PM explain to the > user that he/she needs to unmask a particular version in the tree / > overlay). The problem with repo deps is that they're too restrictive since they assume that only a specific repo can satisfy the dep. Suppose that you migrate some of the packages from the overlay to the main tree? Now you've got installed packages that are trying to pull in deps from the wrong repo. Or suppose that somebody else has an overlay with a compatible package? I think a better way to reference another repo is with the layout.conf approach suggested in the "QA Overlay Layout support" thread [1]. For example, if packages from the java-experimental repo depend on some ebuilds or eclasses from the java-overlay repo, it's specified via a "masters" entry in layout.conf. If any of those ebuilds/eclasses happen to migrate to the main tree then the migration is seamless. [1] http://archives.gentoo.org/gentoo-dev/msg_33c61550b4ed2b7b25dd5a4110e1ec81.xml - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmvMcIACgkQ/ejvha5XGaNmkwCePw/XjWCqZtIXq5yXQ4gpHALL fXUAoMqkmJ30Go2SJaqS2lzs+8axyLwn =ju66 -----END PGP SIGNATURE-----