1 |
Peter Fein wrote: |
2 |
> I think a note saying "DON"T DO THIS UNLESS YOU REALLY KNOW WHAT YOU'RE DOING", |
3 |
> as is done elsewhere would suffice. |
4 |
|
5 |
I disagree, we say that with certain things right now, still users do |
6 |
use it without obviously knowing what they're doing and do file bugs |
7 |
about it. This is experience speaking. |
8 |
|
9 |
> Given the recent volume on ebuild approval, |
10 |
> that's not much of an counter-argument. |
11 |
|
12 |
That's not much of an argument either. The thread agreed with the fact |
13 |
that there were some problems, but they are being worked on. Besides, i |
14 |
know of a lot of open ebuild requests that are still not submitted for |
15 |
whole other reasons (unstable versions, some old unsupported stuff etc.) |
16 |
and probably never will. |
17 |
|
18 |
> I agree that inclusion in Gentoo-proper |
19 |
> is a worthy goal - but as a user, not being restricted to blessed packages |
20 |
> should be my choice (and of course, no one's under any obligation to support any |
21 |
> of this to begin with, but it's worth discussing). |
22 |
|
23 |
You stil have the choice, the main point is i think we shouldn't promote |
24 |
it. 'restricting' users to 'blessed' packages is a guarantee for the |
25 |
best possible experience we can offer, there are ways around it for the |
26 |
bold or whatever you want to call them. Anyway, we still don't restrict |
27 |
them, every serious ebuild submission is considered. |
28 |
|
29 |
> Maybe I'm less scared of |
30 |
> stability issues running Gentoo on a home box that could erupt into flames |
31 |
> without causing me much distress, but this should be a matter of choice, rather |
32 |
> than a policy enforced by software. Such a scheme may actually speed up package |
33 |
> acceptance, as it provides a wider test base prior to inclusion. |
34 |
|
35 |
Or hamper ebuild acceptance (may be better terminology), because people |
36 |
don't feel the need to get it into the Gentoo bugzilla anymore. And |
37 |
testing without feedback hasn't much effect. Testing of non-gentoo |
38 |
packages is ignored, we don't support ebuilds not in the tree. |
39 |
|
40 |
> |
41 |
> I'd be aware I'd be using non-approved ebuilds if I set those vars in the first |
42 |
> place & portage warned/notified me which repository it was installing from. |
43 |
> This architecture rocks - restricting it to approved packages only deprives |
44 |
> folks of a really great tool (wow, I'm sounding awfully "software wants to be |
45 |
> free" today...). |
46 |
|
47 |
More vars, more warnings, increased complexity : it makes great tools |
48 |
less and less usable over time. New features should be considered |
49 |
carefully if they really add something substantial, in my opinion that's |
50 |
not the case here. |
51 |
|
52 |
There is no restriction imposed, 'depriving' people of easily accessible |
53 |
major amounts of low quality, possibly conflicting ebuilds is not a bad |
54 |
thing per se. |
55 |
|
56 |
- foser |
57 |
|
58 |
|
59 |
-- |
60 |
gentoo-dev@g.o mailing list |