unzoo integration [PSARC/2008/183 FastTrack timeout 03/14/2008]

[James Carlson]

Jyri Virkki writes:
> A collection of optional packages, however, is not only useful but
> vital for making [Open]Solaris broadly usable and thus hopefully more
> widely adopted. It is not the role of the ARC, nor of Sun, to mandate
> which components [Open]Solaris users shall be allowed to conveniently
> install[1]. We need to change to a user-centric view where we enable
> users to install whatever they need. If they happen to need unzoo, so
> be it.

In that case, if the repository is somehow a "system" as we presently
know it, then:

  - We ought to think hard about delivering useless items; we've got
    quite an accumulation of stale bits already, and adding to that is
    not good, and bodes poorly for the future.  Garrett's comments are
    on target here.

  - Getting a good solution is better than a short-cut one.  David
    Korn's comments about pax(1) are on target, as centralizing this
    makes for a much nicer system that doesn't have a wild forest of
    abandonware (and likely semi-functional) tools.

  - Getting a complete solution is important.  Darren's comments about
    "unzoo" being incomplete without "zoo" are on target here.

  - In the future, you should not be delivering tools here that
    conflict with each other, as that represents poor system
    architecture ("let the user figure it out"), which in turn means
    that you won't be able to have "alternative" sets of tools in the
    repository -- one function, one tool.

  - Nor should there be duplicates or hacked versions of the same
    object; the regular architectural rules for packaging system
    extensions apply.

... or, if that's too much, then we need new rules.  I'm arguing that
the repository you and David seem to be talking about needs some rules
in order for any architectural review to stay on target, and those
rules *appear* -- based on the responses to the comments here -- to be
different from the ones we would ordinarily use in reviewing system
components.  (I'm not even positive that all of you agree in detail on
what the repository should be.)

Otherwise, we're just going in circles.

> To be useful, this collections needs ARC oversight of the relevant 
> architectural details. Look at debian.

Indeed.  A dumping ground can be bad.

> > But if we're just composing a repository, that argument goes out the
> > window.  There's no _obvious_ lower bar that I can see for
> > integration.  Even rootkits and spam tools probably have a place.
> 
> No there is no obvious low bar (though I'll vote -1 on the spam tools).
> 
> http://en.wikipedia.org/wiki/The_Long_Tail
> 
> Fringe components like unzoo are important not because any one of them
> is wildly popular but because there are so many thousands of them.
> Nobody individually needs most of them, but everyone needs a small but
> different subset.  Applying the popularity argument individually to
> each one leads to leaving them all out ... and an unusable system. And
> so people migrated to Linux.

We've heard the marketing story before.  I don't think that's the
problem.

The problem is that I see no obvious way to map that into a new vision
of what consitutes a "system," so I'd like the proponents of this new
repository mechanism to specify the detailed rules.  And, in
particular, how our existing rules must change to accomodate the new
"back up the truck and dump 'em in" plan that fixes the popularity
issue.

> [1] "Convenientely" is of course the key part. Telling them to go hunt
> down sources and compile it themselves fails the convenience test.
> That was fun back in 1990 but that was a long time ago. Expectations
> are different now.

That's possibly a better argument for BSD-like PORTS.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677