[gentoo-user] Re: How can I unmask package and mask just its one version?

2010-10-30 Thread Nuno J. Silva
Alan McKinnon alan.mckin...@gmail.com writes:

 Apparently, though unproven, at 19:13 on Thursday 28 October 2010, Jarry did 
 opine thusly:

 Hi,
 how can I unmask (generally) certain M~ masked package and
 mask one particular version of that package? I want to use
 that package, but skip just one x.y.z upgrade, and continue
 with any future higher upgrades (x.y.z+1).
[...]
 portage is fighting you.

 unmask has priority over mask, so unmasking everything and masking a specific 
 version will not work - the first rule will prevail.

[example omitted]

 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)

-- 
Nuno J. Silva
gopher://sdf-eu.org/1/users/njsg




Re: [gentoo-user] Re: How can I unmask package and mask just its one version?

2010-10-30 Thread Alan McKinnon
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