On Sun, Nov 21, 2010 at 09:22:24PM +0000, Markos Chandras wrote:
> On Sun, Nov 21, 2010 at 01:30:15PM -0600, Ryan Hill wrote:
> > On Sun, 21 Nov 2010 19:05:44 +0000
> > Markos Chandras <email@example.com> wrote:
> > > > Isn't that the point? People should be discouraged in every way not to use
> > > > live ebuilds. I'd add a third if we had one.
> > > >
> > > > But yes, if I had to pick only one I'd go with dropping keywords over
> > > > package.mask. In fact it looks like I have some live ebuilds in the tree
> > > > that do exactly that.
> > > >
> > > Actually not. Users are already familiar with the -9999 concept so there
> > > is no point to add extra obstacles in their way. I am trying to find out
> > > corner cases where double masking makes sense. Otherwise it makes no
> > > sense to me. Actually the majority of users get confused when a package
> > > is double masked. Just drop by forums etc and you will see
> > Again, that's the point. If you can't figure out how to get around a
> > double mask then you have no business installing live ebuilds.
> > But this is getting off topic. If you want to change the policy to recommend
> > dropping keywords rather than using package.mask then I support it.
> > package.mask has the disadvantage that it's too easy to accidentally unmask
> > live versions with >=. And nothing stops someone from doing both if they
> > want.
> > --
> > fonts, gcc-porting, it makes no sense how it makes no sense
> > toolchain, wxwidgets but i'll take it free anytime
> > @ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
> If the majority of the devs ( at least of those who participate to this
> thread ) is positive, then I will commit a patch to devmanual and
> possibly migrate the cvs&svn sources pages into a single one.
Count me in on this policy change. I think that double masking is a
pain as well.
I would agree that we might want to document somewhere that if
users are using "**" in package.keywords they really get to keep the
pieces, since they will be installing live ebuilds.