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 <gentoo-user+bounces-116073-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1PCB9w-0007hC-N9
for garchives@archives.gentoo.org; Sat, 30 Oct 2010 13:07:48 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D3A39E076B;
Sat, 30 Oct 2010 13:06:47 +0000 (UTC)
Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com [209.85.215.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 8DE06E076B
for <gentoo-user@lists.gentoo.org>; Sat, 30 Oct 2010 13:06:47 +0000 (UTC)
Received: by eyb6 with SMTP id 6so1295876eyb.40
for <gentoo-user@lists.gentoo.org>; Sat, 30 Oct 2010 06:06:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:to:subject:date
:user-agent:references:in-reply-to:mime-version:content-type
:content-transfer-encoding:message-id;
bh=i048QJbdv06eGkrf66fsf1j5xZoScZ01v0sZxG1dQmI=;
b=Fyl5/nFwr+f+Yjd2weq60jTrVhJ2vZ+OgWt3vNsCEv4Vg9FDoGwWD6bz/WCOSxNiOI
ZGGGeiPByTqRPEnkwCsRfSXU9P8jCe8UBvUnXhsk7Sk4sUc8sATCgq/blJw/0wBotSMe
W83C4/fQHh6sdMUWr5kNK0krnixwIrdtmLH9k=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:to:subject:date:user-agent:references:in-reply-to:mime-version
:content-type:content-transfer-encoding:message-id;
b=V1LWt8eQHvVWL+zgSIL30sdDma+eCJauMdWFPnc//nLJjG/CihIRb/zcfSiYf5H24S
q057fpjrCKXowshbBAd6MCDrqNfxOssBnwPsKsF/3uJUFNQissiAz++AwpMIW1ePHfOV
H82an7W2ETtEKaXHer0SakWGuFN7t+P4mVgDo=
Received: by 10.213.108.196 with SMTP id g4mr10962146ebp.31.1288444007025;
Sat, 30 Oct 2010 06:06:47 -0700 (PDT)
Received: from nazgul.localnet (196-215-2-42.dynamic.isadsl.co.za [196.215.2.42])
by mx.google.com with ESMTPS id q58sm2567747eeh.3.2010.10.30.06.06.44
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sat, 30 Oct 2010 06:06:45 -0700 (PDT)
From: Alan McKinnon <alan.mckinnon@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: How can I unmask package and mask just its one version?
Date: Sat, 30 Oct 2010 15:07:19 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.36-ck; KDE/4.5.2; x86_64; ; )
References: <4CC9AF25.7050401@gmail.com> <201010282054.03778.alan.mckinnon@gmail.com> <87fwvnzyla.fsf@ist.utl.pt>
In-Reply-To: <87fwvnzyla.fsf@ist.utl.pt>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201010301507.20075.alan.mckinnon@gmail.com>
X-Archives-Salt: 1dfad1a7-5ae3-4d49-a1b2-47f6564f7990
X-Archives-Hash: df53ae26adcaa47050c165bffd005724
Apparently, though unproven, at 13:53 on Saturday 30 October 2010, Nuno J.
Silva did opine thusly:
> > But this is fragile and will break way too often. What if you later also
> > want to mask version 7? portage doesn't give you a boolean AND or any
> > way I know of to specify a range of versions. So you have to keep an eye
> > on it manually, and tweak as necessary. Or you could just list exactly
> > every version for which there's an ebuild and add it to the appropriate
> > package.* file
> >
> > This is a definite shortcoming in portage, it warrants a feature request
> > at b.g.o.
>
> I'm (not yet?) needing this feature, and I'm not a portage developer,
> but while reading this thread I found myself wondering about ways to
> allow this mixing of mask and unmask - I'm sharing that in case it is
> useful. Feel free to ignore.
>
> - obey the more specific atom, this way unmasking the whole thing in
> .unmask and masking specific atoms in .mask would work. (When they're
> equally specific, use the current behavior.)
>
> This probably involves writing something to tell which atom is the
> more specific, unless that already exists.
>
> An advantage is that the current atom syntax doesn't need to be
> changed.
>
> - add regex support: this would allow exclusion on .unmask, but the
> syntax may not be the best, and it must ensure it doesn't break with
> existing atoms (there are atoms using asterisks and package versions
> have lots of stops)
These are good thoughts. But, the entire topic is insanely complex, but more
so than first appears. If you want to know more, read the C precedence rules,
then read the C compiler code that implements it. Yep, that is what it takes.
The major problems as I see it in doing this for portage is that we lack a
precedence syntax. Putting one in is a major change to portage so not to be
undertaken lightly.
What I would like to see is the distinction between mask and unmask files go
away and be replaced with one file for masks. Prefix "+" (or none) means one
thing, prefix "-" means the opposite - much like USE flags are done.
Finally, there are no implicit rules that will ever fully describe what we
users want to do with masks. At some point there must be an explicit syntax to
cover these - which is what we do with nested parentheses in maths. A good
example of such a syntax is /etc/hosts.allow which allows nesting of ranges.
--
alan dot mckinnon at gmail dot com