Garrett D'Amore wrote:
> unison as documented for this case, IMO, does *not* belong in any
> default distribution of Solaris, but in some value add location where
> folks who want it can get at it easily.
I tend to agree. What's the next step?
It sounds like we need to define some sort of "Solaris Architecture
Scorecard" for these projects and rate them as to what core features
they support, bypass or ignore. Then, armed with factual info rather
than conjecture, we can figure out how to handle them.
myFossProject:
Supports Posix, ufs, I18N
Does not support ACLs, hard links, PAM, network access control...
Should there be different repositories for each type (aka Universes), or
should these scorecard boxes directly correlate to tags in a repository,
or should we simply "closed denied" anything that doesn't pass some lower
bar (with an opinion that gives actionable advice), or ...?
We can't really come up with a good set of solutions until we can
reliably characterize the problem. Are these things replacing existing
components (star's rmt...) or they simply adding new stuff (unison)?
Are they integrated well (audit, smf, acls...) or poorly? Given that
our customers are already downloading the soource for these things,
compiling it on Solaris and using it there, how does our doing the same
thing make matters worse? What are we doing to make both those paths
better?
Rather than complaining, we should be actively figuring out how to solve
this problem:
We want to be able to build the thousands and thousands of
FOSS components out there and make them available to our users.
How can we make this happen?
-John
