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
signature.asc
Description: This is a digitally signed message part
