> From: Danek Duvall <danek.duvall at sun.com> > Date: Thu May 10 10:56:26 2007 > Subject: [ports-discuss] Draft: Open Package Management Proposal > > I think what this document -- and much of the discussion preceding and > surrounding it -- suffers from is a lack of focus. There are a lot of > problems in this area, many of them serious and affecting a large number of > people, and the natural temptation is to plow into it all at once. > > The high-level breakdown as I see it: > > - Need for new packaging tools. This includes improvements to the > existing pkgadd and friends, additions like pkg-get, or some subset of > a wholesale replacement of the packaging system, including, possibly, > package file format. > > - Need for software delivery infrastructure. This is mostly concerned > with where people can get bits, and what expectations they can place on > such repositories with respect to stability, support, freshness, > openness, etc. This is mostly a namespace management and policy sort > of thing, and obviously depends on the previous bullet for the delivery > implementation. > > - Need for a scalable mechanism to build software. This includes the > discussion about the differences between how ON builds vs SFW/CCD vs > JDS/pkgbuild vs whatever else. The goal is to make as much software > available as possible, which means scaling out to lots of developers, > and depending on the previous naming and policy bullet to help users > choose what software is appropriate for their system. > > - Need for a policy on what software should go where. This is all about > /usr/bin vs /usr/gnu vs /opt/csw, and what different directory > locations say about the software that's installed there, as well as > dealing with multiple versions and implementations of essentially the > same software. Each distribution (whether of the core OS, like Sun and > Nexenta, or of unbundled software like Blastwave or sunfreeware) will > have its own policy for this, though some commonality should be a goal. > > Every proposal I've seen so far -- and all the discussion following them -- > has mashed these areas together. A single proposal can (and maybe even > should) address all four areas, but I think clean lines need to be drawn > between them to help focus discussion and, ultimately, implementation. Of > course there's interaction between them, but not so much that they're not > separable.
My only quibble is in the last paragraph and only because the suggestion to do it as a single proposal should be couched in more caution. In specific, each bullet probably needs to be developed in a way that ensures the primary team(s) already working in that area are explicitely asked for early input and ultimately buy-in (or non buy-in). The tricky part is the optimal audience varies somewhat from bullet-to-bullet. Eric
