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
