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
