| 1 |
First I'd like to state that I do offer my opinion. You don't have to like it, |
| 2 |
but disqualifying it as flaming, while exactly doing this yourself, |
| 3 |
disqualifies you. I'd appreciate, if you would try to have a controversial |
| 4 |
discussion, without starting to loose your manners. |
| 5 |
|
| 6 |
|
| 7 |
On Wednesday 02 August 2006 03:39, Brian Harring wrote: |
| 8 |
> 1) no security, |
| 9 |
> |
| 10 |
> Suggest you read their responses, and look into some of their material |
| 11 |
> (in particular their faq). |
| 12 |
> |
| 13 |
> Two levels. |
| 14 |
> |
| 15 |
> One, holding area (essentially). |
| 16 |
> Second level (what users get), is the reviewed branch. |
| 17 |
> |
| 18 |
> So... if you're arguing people can stick malicious shit into the first |
| 19 |
> level, yes, they could. |
| 20 |
> [...] |
| 21 |
|
| 22 |
You haven't read what I wrote, as I asked you to do. My point isn't that |
| 23 |
people add malicious ebuilds to the overlay. There're more subtle methods |
| 24 |
anyway, given that the tree still isn't signed. I wrote about vulnerablities |
| 25 |
in the upstream software, neither having a security team backing them up nor |
| 26 |
GLSA's to be written. |
| 27 |
|
| 28 |
|
| 29 |
> And... just cause I'm mildly sick of this bullshit, |
| 30 |
|
| 31 |
And I'm sick of people, who miss the point. |
| 32 |
|
| 33 |
|
| 34 |
> > 2) issues with eclass changes which will result in bug spam |
| 35 |
> |
| 36 |
> You're not supposed to change the exposed api of eclasses in the tree |
| 37 |
> (something y'all do violate I might add, which is a seperate QA |
| 38 |
> matter). Same issue applies to the 'official' overlays offered by |
| 39 |
> devs also, and to the tree in general. |
| 40 |
|
| 41 |
We can change eclasses all the time, assuming all relevant ebuilds in the tree |
| 42 |
get adjusted - just that no one cares for any overlay. |
| 43 |
|
| 44 |
> It's a reaching statement, bluntly. Using such an arguement has the |
| 45 |
> side affect of stating that no overlays should ever exist, because |
| 46 |
> they suffer the same potentials. |
| 47 |
|
| 48 |
Local overlays are fine as the user exactly knows what he does in his private |
| 49 |
overlay (and hopefully follows eclass changes), development overlays are fine |
| 50 |
(assuming the group of people controls the releavant overlays as well), |
| 51 |
overlays like Sunrise are problematic, not to use such anal words as you do. |
| 52 |
|
| 53 |
> > 3) the fact that sunrise is a bunch of arbitrary packages, instead close |
| 54 |
> > related ones managed by one team, that does exactly maintain relevant |
| 55 |
> > packages. |
| 56 |
> |
| 57 |
> What the hell do you think the tree is? It's a bunch of arbitrary |
| 58 |
> packages maintained loosely by subgroups of people; you're stating |
| 59 |
> that sunrise is too loose yet gentoo-x86 is fundamentally no |
| 60 |
> different. |
| 61 |
> |
| 62 |
> Sunrise is pretty much the same damn thing. |
| 63 |
|
| 64 |
Exactly that isn't right. No one cares for compatibility of the main tree |
| 65 |
(eclasses, conflicts between ebuilds with regards to installed files) and |
| 66 |
Sunrise ebuilds. |
| 67 |
|
| 68 |
|
| 69 |
Carsten |
Archives