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