Nirbheek Chauhan posted on Sun, 08 Nov 2009 05:38:56 +0530 as excerpted:

> We had something interesting happen with policykit. It was masked for a
> very long time, and so all users of policykit had "sys-auth/policykit"
> in p.unmask. Then it was unmasked, but of course who bothers cleaning up
> their local configuration as long as it works?
> 
> Months later, policykit-0.92 was added (masked) which was ABI, API, UI,
> everything incompatible.

> And of course it completely hosed everything on top of X.

> Lesson to be learnt: users are morons with short attention spans[1].

> 1. Of course, we ourselves come under the definition of "users" too.. ;)

Ouch!  I've had something like that bite me (user-side) too, when I 
wondered why my package.mask entry wasn't being honored... I had a 
package.unmask entry too!

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?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman