Gentoo Archives: gentoo-user

From: hasufell <hasufell@g.o>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Gentoo's future directtion ?
Date: Fri, 28 Nov 2014 16:56:23
Message-Id: 5478A922.7070204@gentoo.org
In Reply to: [gentoo-user] Re: Gentoo's future directtion ? by James
1 James:
2 > hasufell <hasufell <at> gentoo.org> writes:
3 >
4 >
5 >> I still don't see a good argument why we made our system so inflexible,
6 >> that obviously needed change needs such high amount of work, PR and proof.
7 >
8 > I think that most folks appreciate your efforts and insightful ideas
9 > on how to open up development, particularly in non-critical (non-core)
10 > areas. The quesiton is how do we get from where we are to where we
11 > want to be. I find most of what I'm interested in already in Arch Linux. I
12 > wonder why it is so much easier for Arch users to create pkgbuilds (like
13 > gentoo's ebuilds) and find a dev to adopt the package? Surely someone has
14 > some insight on this differences, or do I miss something that creats the
15 > difference? [1] I also find the Arch documentation to be of the finest
16 > quality of any and all linux distros, close to gentoo. ymmv.
17 >
18 >
19
20 Arch has done it wrong, IMO. Sure, their PKGBUILDs are easier to write,
21 but their quality is also worse. I know how to write them and have
22 written and looked at a lot of them.
23
24 People went the easy way and didn't really care much about review
25 workflow, so they ended up with AUR where everyone can upload random
26 stuff, including dangerous and wrong code.
27
28 >> Trying to improve a tiny fraction about gentoo workflow (including your
29 >> attempts) already took more than 4(?) years with never ending excuses.
30 >> The necessity was more than obvious.
31 >> Now I could talk about similarly obvious things. Sure, not all issues
32 >> are obvious and those shouldn't be easy to push through.
33 >
34 >
35 > Everyone understands small changes and all changes take time for the
36 > majority of members to digest, imho. Not everyone has your keen insight into
37 > the problem/opportunity. So your patience in explanation, encouragement and
38 > solicitation, is very important, if your idea is to be
39 > implemented and tested. Naturally, Rich and other deeply involved devs, with
40 > addtional responsibilities exude caution, to keep the gentoo stable.
41 > They will not be the source of "team building" for your idea, imho.
42 >
43
44 Gentoo isn't even particularly stable anymore. It's a mess to maintain
45 with a confused PM, toolchain hackery and random conflicting ideas in
46 one repository (e.g. multilib clashing with crossdev).
47
48 The distro can only be as stable as the PM and the PM depends on the
49 input. The input depends on quality ebuilds. Quality ebuilds depend on a
50 proper spec, but there is no proper spec... PMS team itself says it
51 started as a collection of ancient portage behavior and then grew with
52 time, so there was no real design behind it. Quality ebuilds also depend
53 on review-workflow. Review-workflow needs proper tools.
54
55 We don't even have the last one. Long way to go. Good luck.
56
57
58 >> You can draw your conclusions about this. I drew mine: small changes
59 >> will not get us out of here.
60 >
61 >
62 > I think the jury is still out. So, why can't we test a transient plan
63 > where we take something very broken areas at Gentoo (games or java or
64 > sys-cluster) and test out your hypothesis for package development expansion?
65 >
66
67 Already doing so
68 https://github.com/hasufell/games-overlay
69
70 and that's where I will update ebuilds, not in the tree. And I don't
71 care to get any of that into the tree.
72
73 > In fact, I've been looking over quite a few ebuilds and pkgbuilds at (Arch
74 > linux). [2] I see quite a lot of commonality. So, why can we not "modify"
75 > this aforementioned "inflexible" system on gentoo to allow for Arch Linux
76 > pkgbuilds to be routinely compiled and installed on gentoo?
77 >
78 > Maybe limit the test to /usr/local/portage or /usr/local/portage/test/ so
79 > folks can participate or purge the experiment? Maybe find some Arch linux
80 > devs keen on the idea of developing/evolving package management so that
81 > the two distros can readiy (or more easily) convert packages between
82 > Arch and Gentoo? Is it possible? Could your plan be modified to
83 > include a variety of Arch developers? Surely you have a collection
84 > of devs ready to implement your keen ideas? I, for one realize something
85 > fundamental has to change with Gentoo, after pushing a few months
86 > on java and cluster codes.... Also, there is a vast array of software,
87 > of various quality, among the overlay repositories to use as test-packages?
88 >
89 >
90 > The biggest thing I seen wrong with Arch is they have forced systemd
91 > onto their users, and all of the arch users I know, are not very
92 > happy about that. So if you approach this correctly, I'm sure quite a
93 > few Arch linux folks would also test your offerings.
94 >
95 >> Have fun, if you can.
96 >
97 >
98 > Always we should have fun. That is why we should deeply discuss these
99 > issues to find common ground. Maybe fixing this inflexible system should
100 > involve a survey of those distros closest to gentoo, for ideas, particulary
101 > several (structured) methods to install packages, provide choices for the
102 > init system, and strongly advocate package development within the
103 > ranks of the user base. Clear and concise documentation, concurrent with
104 > this effort is probably your single greatest alley, should your idea
105 > and leadership prove successful.
106 >
107 >
108
109 People are scared of other gentoo-like distros/PMs. Exherbo is evil,
110 paludis is evil, sabayoon is evil, ...
111
112 I've already tried contributing to exherbo. They are technically ahead
113 of us in some non-trivial areas, but I don't think they have solved the
114 contribution problem. Sure, they are more distributed and have gerrit
115 etc, but their review workflow goes more the way "make a high-quality
116 user-overlay and then we will review it once and add it to our page".
117
118 They don't care too much about themed and clearly scoped overlays and
119 about the difference of 'modular' and 'fragmented'.
120
121 200 guys pushing into 200 repositories without _regular_ reviews (not
122 just a "gentoo dev" or "high quality" overlay badge) is not much
123 different to what gentoo does.
124
125 Arch is neither interesting from the technical nor from the workflow
126 standpoint, IMO.

Replies

Subject Author
[gentoo-user] Re: Gentoo's future directtion ? James <wireless@×××××××××××.com>