Re: [gentoo-dev] Re: QA: package.mask policies

[Vlastimil Babka]

Duncan wrote:
> In theory that's what those stupid version string thingys are for, but
> it's soooo much easier just to forget one! =:^[
>
> Maybe something about this should go in the handbook -- a suggestion that
> if one is going to use a package.unmask entry, that they copy the
> package.mask entry over, thus at least letting the devs minimize the
> version spread damage with their package.mask entries.  That's what I've
> started doing, and it works surprisingly well, as I have right there the
> comment on why it was masked (and add a comment on why I'm unmasking,
> when I think I might wonder, later), and it's the exact same versions the
> devs masked in the first place, so I don't have to worry so much about
> unintended version spread -- at least as long as the devs doing the
> masking worried about it then. =:^)
>
> What do you devs think?  Would that be a practical hint for the
> handbook?  Would it be helpful in allowing /you/ to control the version
> spread of the unmask, by consequence of your control of the version
> spread on the mask in the first place?

Hi,

handbook is one thing, but maybe portage could make it more prominent 
when it displays the packages to be merged, so that the users hopefuly 
notice?
- visibly distinguish (red color and stuff?) packages that are to be 
installed thanks to package.unmask or ** keyword
- print extra warnings about those entries in package.unmask and ** 
keywords that are not version restricted, if they contain the packages 
to be merged. This could follow the suggestion above - aside from the 
distinguished packages, below the list and above the yes/no (if --ask is 
used) there would be "Warning: the following packages have broad 
unmasks, you sure you want these versions?" and the list.

Vlastimil