1 |
Great response, but I just have to express my difference of opinion here. |
2 |
|
3 |
> Gentoo will never be easy, |
4 |
> but it is a very flexible and through solution for many areas of need. |
5 |
|
6 |
That flexibility means we who chose to participate in 'building' Gentoo |
7 |
have the power to make it as flexible as we want. I want a future where |
8 |
the ebuild is up there with Make files as a 'standard tool' in the arsenal |
9 |
of software developers, and nothing stops us making it happen. |
10 |
|
11 |
There are good examples out there for this: |
12 |
The AUR on Arch Linux, shows how with the right tools and documentation |
13 |
like, https://wiki.archlinux.org/index.php/PKGBUILD, |
14 |
https://wiki.archlinux.org/index.php/Creating_packages#PKGBUILD_functions, |
15 |
and https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages. |
16 |
and also NetBSD with their pkgsrc tools are very well developed |
17 |
(http://www.netbsd.org/docs/pkgsrc/faq.html#faq-pkgtools) |
18 |
in particular url2pkg and pkglint which let you just 'bootstrap' a package |
19 |
from just a URL to a source tar ball and pkglint, this kind of code shows |
20 |
how easy package creation can be, I think we could even have a web |
21 |
interface for people to submit new software into the 'experimental' pile |
22 |
so that a hypothetical Gentoo CI system can test them out. |
23 |
|
24 |
The power at our disposal could even let us 'harvest' the AUR and |
25 |
other software sources mechanically with daily scripts to download |
26 |
their packages, analyse them and build new packages for us. |
27 |
Obviously this would require some effort to build things like |
28 |
dependency translation lists, but to be honest, anything to do |
29 |
with package management is a DEEP rabbit hole we can go down. |
30 |
|
31 |
At the moment the more I learn about the ChromeOS tools the more |
32 |
I wonder if I should start counting every ChromeOS, device as a |
33 |
'Gentoo installation that doesn't know it'. Early next year I will probably |
34 |
buy a ChromeBook Pixel in order to experiment more with just how |
35 |
easy it is to put the 'full power' back on top of the ChromeOS base. I |
36 |
suspect it won't be hard, the dev tools let you build packages and push |
37 |
them to a ChromeOS device over the network, I should be able to just |
38 |
either push any new package I want from my sever to the laptop. |
39 |
Or just push portage itself back onto the device. |
40 |
|
41 |
Mindful of the aforementioned rabbit hole, |
42 |
I'll stop myself here and sum it up by saying that I don't see any |
43 |
reason Gentoo must be hard. |
44 |
|
45 |
|
46 |
On 17 December 2014 at 23:37, James <wireless@×××××××××××.com> wrote: |
47 |
> Sam Bishop <sam <at> cygnus.email> writes: |
48 |
> |
49 |
> |
50 |
>> Very interesting. A great example of how something can be both Gentoo |
51 |
>> and Not Gentoo. This is 100% Gentoo unlike Funtoo or Sabayon, but it |
52 |
>> brings in some of their advantages. Gentoo doesn't prevent us from |
53 |
>> having multiple package variants and this leads to cool stuff like |
54 |
>> being able to have a set of layman repositories that ebuilds graduate |
55 |
>> through in stages, from 'dev' to 'test' to 'stable'. |
56 |
> |
57 |
> Zentoo is certainly a site worth closer examination for CI ideas. |
58 |
> |
59 |
> I also see folks running CI locally on the codes they build |
60 |
> and specifically need to be very robust. Epatch_user is another |
61 |
> need for folks to employ CI on their own (local cluster), imho. |
62 |
> |
63 |
> |
64 |
> |
65 |
>> And this is why I feel so strongly about Gentoo + Git + CI |
66 |
>> While github may not be the right place and raw 'git' not the right |
67 |
>> tool. I am a big fan of how phabricator + arcanist provides workflow |
68 |
>> guarantees on top of using git, such as the 'must pass the linter |
69 |
>> rules + tests' workflow and how it can track and reference external |
70 |
>> repos side by side with the repos it hosts. |
71 |
> |
72 |
> I ran across a recent thread [1] on another list about gentoo vs some |
73 |
> of the other more common distros. Folks seem to be firmly in either |
74 |
> camp; but more in the conventional distro camp. What I did find interesting |
75 |
> is lots of corporations are running on hundreds of gentoo systems |
76 |
> and using (chef, puppet, ansible or salt) to ease the management of large |
77 |
> gentoo deployments. It's just nice to know that despite what many say (use a |
78 |
> mainstream distro) Gentoo is alive and doing very well in the corporate world. |
79 |
> |
80 |
> I just wonder why more of them do not openly share management strategies |
81 |
> for large gentoo deployments....? |
82 |
> |
83 |
> [1] http://www.reddit.com/r/linuxadmin/comments/2nkswx/gentoo_in_production/ |
84 |
> |
85 |
> |
86 |
> |
87 |
>> I feel the future belongs to Gentoo as steward of the ebuild format, |
88 |
>> portage and related tools more than as a 'meta distro'. CI is the |
89 |
>> force multiplier, when anyone who wants to build a "Gentoo powered |
90 |
>> distro" has a documented set of tools they can use to 'stand up the |
91 |
>> infrastructure' for things like package QA using a CI Server, a Binary |
92 |
>> Package build server/server farm, and Binary Package hosting for the |
93 |
>> build artefacts. By rights Gentoo not Debian, Arch or Fedora should be |
94 |
>> the Distro of choice for creating experimental niche distros from but |
95 |
>> we lack the kind of tools to make it 'easy' for people to do. I'm |
96 |
>> currently experimenting to see how many of these I can prototype |
97 |
>> inside Docker containers or LXC images and it looks quite promising. |
98 |
> |
99 |
> I'm just now learning and experimenting with docker and LXC. 'etest' |
100 |
> is an interesting tool one of our devs is putting together in the spirit |
101 |
> of testing combinations of flags for testing [2]. |
102 |
> |
103 |
> [2] https://github.com/alunduil/etest/ |
104 |
> |
105 |
> I could not agree more. I think Gentoo is on the verge of an emerging |
106 |
> recognition not only of it's uniqueness, but that it fills a gap sorely |
107 |
> need. |
108 |
> |
109 |
> I think that if CI and clusters become, "routine" for the masses of gentoo |
110 |
> users, that will spring-board our rank and file members into jobs deploying |
111 |
> Gentoo deeply into the business world. What extremely talented folks have |
112 |
> done with Gentoo, I've seen many many times. Taking that power and |
113 |
> intentionally making it available to the ordinary linux admin (average |
114 |
> skills) could easily revolutionize the computing landscape. Gentoo will |
115 |
> never be easy, but it is a very flexible and through solution for many |
116 |
> areas of need. |
117 |
> |
118 |
> Zentoo and the (corporate usage thread) I posted all tell me that Gentoo |
119 |
> is not only alive and doing well, it is on the move! |
120 |
> |
121 |
> |
122 |
> James |
123 |
> |
124 |
> |
125 |
> |
126 |
> |
127 |
> |
128 |
> |