From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 25A201382C5 for ; Fri, 23 Mar 2018 16:20:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C1E2FE08F0; Fri, 23 Mar 2018 16:20:35 +0000 (UTC) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4A930E0849 for ; Fri, 23 Mar 2018 16:20:35 +0000 (UTC) Received: by mail-wm0-x243.google.com with SMTP id l9so4605893wmh.2 for ; Fri, 23 Mar 2018 09:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=w2R3+31sCsMkXIoaWShSpQ2KT+krxZ1Bzad2M/KphQg=; b=eBQmYnZBqkztph5KH7fwtxuW+IHAVAltTQVJXgtS5x6/Bdbaj27aaKgEE9sGjxtUyu VAQY90GMC7qYU/QhM+iYEQDM7yuQLqFkD1mFYwSfvImqNYdnrhEq9ZtV35QLB39QGjJ4 5bN1sdw4DuALpMLO7Q+Ze7fSgiWlB/4XSaYbiSh0OTwUwWakKtxef1uSrarUNK16t8/u a+TK7JhXdBJCnzlXOgJ2BxOmgKO+8kq5kglmuQm9athcMXReBpaSFRW+1DovbbTyCbSQ tKJDTjizbgW6+h1aiMLSFVfnLPOlM90rjlTYNKxlZQJj/zx9kEbxnG17DBKP6atll9Qa ezwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:mime-version:content-transfer-encoding; bh=w2R3+31sCsMkXIoaWShSpQ2KT+krxZ1Bzad2M/KphQg=; b=q3tG/LdEoVxA7gLr56GKQckfX+KafZXi3JZdW3pwjdyCoCAWy90P10Kb47Su58lOGU +vscA5c/uf1seG+P6Nyi2rHXxierU/BClh/OVr3GsI5ysvrlorExjzuh/iTfHSVrcmvP Dfv0Bd1EiGzP9ykVzO0wILhTyNHDvF3iaeoMwDWCP8IFVrqgvnrCNacZscNZNBgfIf2x qXTOZp4+SCUhyLP93oKeb/P1nwY+5nO3bN25pUxJEifDUWvTFCmOzGOnSFvYN0vQ7izJ Ok+Ihp4sptKq0vi6CBtf5+wgJIs4evLqh4Nnxhiee7qZXRbalQHBrvY52H6T/gM7AV2G FJrw== X-Gm-Message-State: AElRT7Hs+/BjAOf0JHUo9sHUG287ozjJb5RxDlyCjhdQXJC8Elak2o9r Ta04MBtOrKs8YZ6mn2sGH/q+vA== X-Google-Smtp-Source: AG47ELsk+LoBVK93YP/8/t9gvFkZK+Egvvcxpytoeja4Jqu6lXssjZOj19ZMfYJfyzfBQnzBs1r3BA== X-Received: by 10.28.91.65 with SMTP id p62mr4453414wmb.140.1521822033112; Fri, 23 Mar 2018 09:20:33 -0700 (PDT) Received: from [192.168.1.104] (host170-152-static.43-88-b.business.telecomitalia.it. [88.43.152.170]) by smtp.gmail.com with ESMTPSA id k1sm11785189wrf.66.2018.03.23.09.20.31 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 23 Mar 2018 09:20:31 -0700 (PDT) Message-ID: <1521822030.4906.39.camel@gmail.com> Subject: Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny From: Geaaru To: gentoo-dev@lists.gentoo.org Date: Fri, 23 Mar 2018 17:20:30 +0100 In-Reply-To: References: <23220.52565.280134.566970@a1i15.kph.uni-mainz.de> <23220.56844.278087.25609@a1i15.kph.uni-mainz.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 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 Content-Transfer-Encoding: 7bit X-Archives-Salt: d4ec84b9-afe2-4d37-a53d-a54f9d82e055 X-Archives-Hash: 9f53def2f7e5b14a22f310fab9717eeb Hi guys, sys-devel/gcc::repos is only an example but from my side it is a real example. Currently, Sabayon use our gcc ebuild so it is needed mask gentoo version for rebuild sabayon-stage3 and now it is only possible (like other packages) through file (from sabayon side): /etc/portage/package.mask/00-sabayon.package.mask My idea is permit to define this mask rules under sabayon overlay as profile and/or as targets. Interesting idea is opposite scenario propose by Barsnes about block overlay packages. Thank you to all for feedback about this proposal. G. On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freeman wrote: > > It sounds to me that one of the intended behaviors is to tell > > portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we > > want > > portage to stick with foo-3 from the overlay. However, if the > > overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask > > would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when > > making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where > > the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in > package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve >