On Sun, Nov 8, 2009 at 1:08 PM, Nirbheek Chauhan <nirbh...@gentoo.org>wrote:
> On Sun, Nov 8, 2009 at 12:33 AM, Duncan <1i5t5.dun...@cox.net> wrote: > > 2) That won't necessarily stop the bugs from rolling in. Some devs may > > get tired of live pkg bugs and package.mask it, thus putting up a double- > > barrier to the live ebuild. If users jump BOTH barriers and fall over > > the ledge, well... maybe they /need/ that Darwin Award! =:^] > > > > 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. Naturally portage on said users' boxes > was very happy to see such an update on the system and it very > promptly upgraded policykit. > > And of course it completely hosed everything on top of X. > > We received bug reports for this a *long* time after adding it. After > getting sick of duping, and since the new ebuild was broken in a few > ways too (and we had decided to rename policykit-0.92 it to > sys-auth/polkit), we finally decided to remove it. > > Lesson to be learnt: users are morons with short attention spans[1]. > But we cannot ignore that fact. > > > In such cases users should be using version specific/version ranges for p.keywords/p.unmask. I don't recall seeing much literature on this practice though with regards to standard recommendations of users and how they should use their own p.keywords and p.unmask. Maybe a good standard practice would be to *not* use ranged p.masks and have explicit =version p.masks, so that users who use the commonly available scripts that just copy from p.mask to p.unmask don't get silently bitten as a consequence. -- Kent perl -e "print substr( \"edrgmaM SPA nocomil.i...@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
