1 |
On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: |
2 |
> On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote: |
3 |
> > On 06/01/06, Brian Harring <ferringb@g.o> wrote: |
4 |
> > |
5 |
> > > Probably better to iron out what y'all actually need and what the dev |
6 |
> > > community is willing to put up with. |
7 |
> > > |
8 |
> > > Eg, would do some research into it, read the archives from last few |
9 |
> > > wars over it, in general find (and address) the issues that lead to |
10 |
> > > glep19 going still born. |
11 |
> > |
12 |
> > The problems being: |
13 |
> > |
14 |
> > 1) Manpower. There are already 10,000 open bugs in bugzilla (and |
15 |
> > growing) without adding more. |
16 |
> |
17 |
> This is probably the primary reason it died. This, of course, ties in |
18 |
> greatly to #2. |
19 |
|
20 |
Automation can reduce workload, within limits. Fex, scripting for |
21 |
yanking packages/deptree out of normal tree for merging into a g19 |
22 |
tree. |
23 |
|
24 |
Doing it by hand is possible, but error prone- same reason we have |
25 |
ekeyword, bit harder to screw things up via ekeyword (and it's a bit |
26 |
quicker in use then loading up $EDITOR). |
27 |
|
28 |
|
29 |
> > 2) Lack of interest. Most developers aren't interested in supporting |
30 |
> > "old" packages. |
31 |
|
32 |
I tend to believe interest is there- specifically resources/manpower |
33 |
to do it. |
34 |
|
35 |
That said, I don't think anyone has yet provided the folks who are |
36 |
interested any way to help- hell, can't even tap interested folk to |
37 |
help with maintaining the ebuild subset at this point since their is no |
38 |
subset. |
39 |
|
40 |
Hell, script work that needs be done, nothing has been done in that |
41 |
direction either- again, specifics haven't been stated, so there isn't |
42 |
anything to contribute on. |
43 |
|
44 |
Not going to find people doing all the work for you, but if |
45 |
_something_ were available for people to build from I'd expect more |
46 |
folks to jump in and help. |
47 |
|
48 |
|
49 |
> The only real "subset" that can easily work without dramatically |
50 |
> increasing workload is to limit to only arch rather than both arch |
51 |
> and ~arch. This is simply because it can be scripted. |
52 |
|
53 |
Agreed on pulling from arch. |
54 |
|
55 |
|
56 |
> > 3) The enterprise. Both of the above problems would be fixed if |
57 |
> > enterprises were contributing developers and/or money. However, they |
58 |
> > aren't, so why is that? The truth is most enterprises want to go to a |
59 |
> > big company to buy their software. They want one homogeneous binary |
60 |
> > system, not a flexible way of building packages from source, and they |
61 |
> > want someone else to do it and be responsible for it. |
62 |
> |
63 |
> While I don't think enterprise support is necessary to accomplish a |
64 |
> stable portage tree, it certainly wouldn't hurt. |
65 |
|
66 |
Tend to think either we wait for someone to step in and contribute |
67 |
(potentially waiting a _long_ time), or just do it. |
68 |
|
69 |
Kind of obvious my preferred route is "just do it" ;) |
70 |
|
71 |
|
72 |
> Truthfully, for any "large" enterprise, the company will be maintaining |
73 |
> a fair number of their own packages, with custom patches and whatnot. |
74 |
> Where I work, we use Red Hat Enterprise Linux. Why? Because we can pay |
75 |
> for support. That isn't the point I am going to make here, however. We |
76 |
> also have to maintain several hundred RPM packages that either are not |
77 |
> included in RHEL or modified by us in some way. What this means is we |
78 |
> are now in the business of maintaining a package set, using arguably |
79 |
> inferior tools versus ebuilds and portage. The binary support in |
80 |
> portage does make it very possible to "build once, deploy everywhere" |
81 |
> quite easily. |
82 |
|
83 |
The binary support is a bit weak- realistically, for a binpkg distro |
84 |
based off of gentoo, it would need a bit of an enema to improve it. |
85 |
|
86 |
So... consider that a statement of "proposals welcome on how to |
87 |
improve it". Right now, since (same with ebuild support) the format |
88 |
is effectively hardcoded into portage, it's hard to replace/make large |
89 |
changes to binpkg format. Abstraction work has/is underway to resolve |
90 |
that (something that help would be appreciated on also). |
91 |
|
92 |
~harring |