+1 - without a doubt
Danek Duvall wrote:
> 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.
>
> Danek
