Gentoo Archives: gentoo-dev

From: Carsten Lohrke <carlo@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Date: Fri, 09 Jun 2006 15:54:11
Message-Id: 200606091744.27131.carlo@gentoo.org
In Reply to: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification by Stefan Schweizer
1 On Friday 09 June 2006 14:04, Stefan Schweizer wrote:
2 > Please, do not assume our users being stupid. They know that they are using
3 > an ebuild from the sunrise overlay with zero support. They deliberately
4 > typed
5
6 You have said stupid, not me. Some won't care enough, I'm quite sure about
7 that. We had such invalid bug reports occasionally in the past and I expect
8 this to happen more often, the easier and more common dealing with overlays
9 becomes. Regarding "zero support": Making this abslutely clear is what I miss
10 looking at overlays.g.o.
11
12 > "svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application"
13 > "emerge application"
14 >
15 > And also there are only applications from maintainer-wanted or
16 > maintainer-needed allowed in the overlay. Because packages are not supposed
17 > to overwrite files from other ebuilds it is unlikely that they can cause
18 > any damage to applications that have not been directly installed from the
19 > overlay.
20
21 maintainer-needed is imho not acceptable at all, as any dev trying to clean up
22 bugs, won't know if a bug report comes from a user of the main tree ebuild or
23 from your overlay.
24
25 > > Also some warning that an overlay may
26 > > break the tree or fubar the users system
27 >
28 > That is not the intention of the overlay.
29
30 If it were intended, it would be malicious. Even if not intended, it doesn't
31 mean tree breakages won't happen. Some dev may change an eclass, without
32 taking overlay ebuilds into account (and he doesn't have to), but the change
33 may break all ebuilds inheriting the eclass in an overlay, leaving all the
34 users of the overlay with a broken tree. And to make that clear: Eclasses in
35 overlays are only "sort of" acceptable, when the same team handles the eclass
36 in the the main tree, as eclasses in overlays hide the main tree eclasses.
37
38
39 Carsten