On Fri, 2006-01-06 at 09:39 -0800, Brian Harring wrote:
> Automation can reduce workload, within limits.  Fex, scripting for 
> yanking packages/deptree out of normal tree for merging into a g19 
> tree.

Exactly, though I am not sure GLEP19 is the right way to go anyway, as
it still put a decent additional load on ebuild developers.

> 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.

That is the primary thing my proposal aims to solve... to give people
something to work on.

> > 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).

Perhaps a good explanation of the binpkg format would be in order to
give us a chance to determine what could/should be changed?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux