On Thursday 25 November 2010 00:12:03 Dane Smith wrote: > On 11/23/2010 08:30 PM, Mark Loeser wrote: [...] > > I'm personally against such a change and would infact like to see all > > live packages nuked from the tree and moved to some experimental tree. > > If you move them there, I don't care what policies you apply, but we > > should try to maintain a solid set of working packages in the main tree, > > which no one can guarantee with a live ebuild. I know most people > > aren't going to agree with me, but I felt the need to say it anyway. > > I know I'm still new around these parts, but I'll offer my two cents > anyway. Take it for what you will. > > There are two mini-discussions I see going on: > 1) Making the use of said 'live' ebuilds simpler and more convenient. > 2) The purpose of live ebuilds and their eligibility to be in the tree. [...] > As to number two, I would be inclined to agree that perhaps they should > be moved to a separate tree/overlay. I realize this is a major > undertaking, and is probably less than feasible, however, I have never > been a major fan of live ebuilds in the main tree. Either use a > snapshot, or move it to an overlay. Live ebuilds are a QA nightmare and > do not belong in the main tree. Only stable and experimental should be > in there. If that occurs, the discussion can be rendered somewhat moot. > KEYWORDS="" and no p.mask entry. They're in their own overlay, and > there's no worries as far as stability or the main tree so the p.mask > policy could safely be done away with.
There's no worry to have about stability or anything with empty keywords; whereas with overlays I'm always worried to find an ebuild that will turn off sandbox and rm -rf /, or do nasty things at global scope, etc. I fail to understand why you claim that live ebuilds are a QA nightmare, you may want to have a look at how I play with, eg, ffmpeg or vlc and their live ebuilds: they make version bumps much easier and far less error prone. A.
