[arc-discuss] Discussion requested for a new ARC Policy on "Expectation Taxonomy and Repository Requirements"

[Shawn Walker]

On Wed, Apr 16, 2008 at 3:39 PM, Ceri Davies <ceri at submonkey.net> wrote:
>
> On Wed, Apr 16, 2008 at 12:04:07PM -0500, Shawn Walker wrote:
>  > On Wed, Apr 16, 2008 at 11:08 AM, Ceri Davies <ceri at submonkey.net> wrote:
>  > > On Wed, Apr 16, 2008 at 10:34:38AM -0500, Shawn Walker wrote:
>  > >  > On Wed, Apr 16, 2008 at 10:16 AM, Ceri Davies <ceri at submonkey.net> wrote:
>  > >  > > On Tue, Apr 15, 2008 at 09:30:32PM -0700, John Plocher wrote:
>  > >  > >
>  > >  > >  > The IPS/pkg repository and associated packaging system must
>  > >  > >  > have the following abilities:
>  > >  > >  >
>  > >  > >  >     1. It must allow packages to be tagged with an "expectation
>  > >  > >  >        level" taken from the (evolving) set of
>  > >  > >  >        [Sandbox, Prototype, Experimental, Preferred, Core]
>  > >  > >  >     2. It must treat these expectation levels as namespace
>  > >  > >  >        qualifiers, such that packages of the same name may
>  > >  > >  >        coexist in a repository with different expectation levels
>  > >  > >  >     3. It must allow the user to select which expectation
>  > >  > >  >        level(s) to choose packages from for installation
>  > >  >
>  > >  > I'm rather uncomfortable with the attempts here to seemingly codify
>  > >  > "as a rule", the capabilities of a software product (ips in this
>  > >  > case).
>  > >
>  > >  So design of the system is undesirable?
>  > >
>  > >
>  > >  > >       4. It must allow for some mechanism for a build to be
>  > >  > >          reproduced exactly at any given future time, whether
>  > >  > >          that be explicit versioning and infinite retention,
>  > >  > >          or preferably just allowing users to clone and retain
>  > >  > >          versioned repositories on local optical media as well
>  > >  > >          as on "the network".
>  > >  > >
>  > >  > >  The idea that everything I need to rebuild a system may not be available
>  > >  > >  is worrying.
>  > >  >
>  > >  > As nice as that would be to have, I don't think it is a realistic requirement.
>  > >
>  > >  I think you've misunderstood me.  Bart Smaalders suggested that most of
>  > >  what comes with Solaris now may now longer be provided on optical media,
>  > >  but rather would be delivered from the network repository.  Given that
>  > >  statement, I am concerned that should I need to build a new system to
>  > >  match a system I already have installed that I should be able to do so.
>  >
>  > I misunderstood what you meant by "rebuild" -- I thought you meant
>  > *recompile* all the software on the system :-)
>  >
>  > Imaging an entire system for re-deployment elsewhere seems outside the
>  > realm of the packaging system and better suited to distribution
>  > construction or other tools.
>
>  I don't wish to have to roll my own distribution of Solaris Next.  I
>  want to use the Sun supported one.  I'm not even talking about imaging a
>  system.
>
>  Currently, I can get a Solaris 10 DVD and install everything on it.  I
>  can then do the same thing at any later point and get a system that
>  looks exactly the same.  I *must* be able to do that with Solaris Next
>  as well, or I will be looking for a different UNIX.

I'm fairly certain you're going to be able to do this.

There is a variety of tools or other functionality that can accomplish
this task.

I would encourage you to discuss your concerns on the pkg-discuss mailing list.

>  > >  We're talking in the context of Solaris Next, as I understand it.  If
>  > >  the repository software is unable to deliver the functionality, then Sun
>  > >  will likely find it hard to provide no matter how much I pay them.
>  >
>  > I'm still confused as to why software requirements are being proposed
>  > to ARC instead of pkg-discuss.
>
>  The ARC want to talk about it is a good enough reason for me.

I still think it should be discussed on pkg-discuss first.

-- 
Shawn Walker

"To err is human -- and to blame it on a computer is even more so." -
Robert Orben