On Fri, Jan 06, 2006 at 10:05:49AM -0500, Chris Gianelloni wrote: > On Fri, 2006-01-06 at 09:00 +0000, Chris Bainbridge wrote: > > On 06/01/06, Brian Harring <[EMAIL PROTECTED]> wrote: > > > > > Probably better to iron out what y'all actually need and what the dev > > > community is willing to put up with. > > > > > > Eg, would do some research into it, read the archives from last few > > > wars over it, in general find (and address) the issues that lead to > > > glep19 going still born. > > > > The problems being: > > > > 1) Manpower. There are already 10,000 open bugs in bugzilla (and > > growing) without adding more. > > This is probably the primary reason it died. This, of course, ties in > greatly to #2.
Automation can reduce workload, within limits. Fex, scripting for yanking packages/deptree out of normal tree for merging into a g19 tree. Doing it by hand is possible, but error prone- same reason we have ekeyword, bit harder to screw things up via ekeyword (and it's a bit quicker in use then loading up $EDITOR). > > 2) Lack of interest. Most developers aren't interested in supporting > > "old" packages. I tend to believe interest is there- specifically resources/manpower to do it. That said, I don't think anyone has yet provided the folks who are interested any way to help- hell, can't even tap interested folk to help with maintaining the ebuild subset at this point since their is no subset. Hell, script work that needs be done, nothing has been done in that direction either- again, specifics haven't been stated, so there isn't anything to contribute on. Not going to find people doing all the work for you, but if _something_ were available for people to build from I'd expect more folks to jump in and help. > The only real "subset" that can easily work without dramatically > increasing workload is to limit to only arch rather than both arch > and ~arch. This is simply because it can be scripted. Agreed on pulling from arch. > > 3) The enterprise. Both of the above problems would be fixed if > > enterprises were contributing developers and/or money. However, they > > aren't, so why is that? The truth is most enterprises want to go to a > > big company to buy their software. They want one homogeneous binary > > system, not a flexible way of building packages from source, and they > > want someone else to do it and be responsible for it. > > While I don't think enterprise support is necessary to accomplish a > stable portage tree, it certainly wouldn't hurt. Tend to think either we wait for someone to step in and contribute (potentially waiting a _long_ time), or just do it. Kind of obvious my preferred route is "just do it" ;) > Truthfully, for any "large" enterprise, the company will be maintaining > a fair number of their own packages, with custom patches and whatnot. > Where I work, we use Red Hat Enterprise Linux. Why? Because we can pay > for support. That isn't the point I am going to make here, however. We > also have to maintain several hundred RPM packages that either are not > included in RHEL or modified by us in some way. What this means is we > are now in the business of maintaining a package set, using arguably > inferior tools versus ebuilds and portage. The binary support in > portage does make it very possible to "build once, deploy everywhere" > quite easily. The binary support is a bit weak- realistically, for a binpkg distro based off of gentoo, it would need a bit of an enema to improve it. So... consider that a statement of "proposals welcome on how to improve it". Right now, since (same with ebuild support) the format is effectively hardcoded into portage, it's hard to replace/make large changes to binpkg format. Abstraction work has/is underway to resolve that (something that help would be appreciated on also). ~harring
pgpz8eZVbUoZQ.pgp
Description: PGP signature
