Brian Gupta wrote:
> Currently we are have reached a point where we have Conary packaging
> system running on Solaris (both Sparc and x86).
> We seek guidance as to the proper course of action. (What criteria is the ARC
> looking for?)
There are several questions that come to my mind on this (or,
indeed, any packaging effort - rpm, yum, apt-get, conary or
even ips):
0) A meta-question to the community at large:
There is a larger question of how we (the community) deal with
potentially divisive proposals like this. In particular, do
we have effective mechanisms ands structures in place to answer
the question of "do we really *want* to do this?" - and if so,
how do we invoke them in this situation?
1) Why are we doing this?
[Reasonable answers might highlight the value received, such
as "if we did apt-get, we'd be able to leverage the thousands
and thousands of debian rpm packages already built". There
are unreasonable answers as well; many fall into the "I just
want to be arbitrarily different, with little absolute gain"
bucket. What can't we do today that justifies the pain of
changing?]
2) What is the intended usage scope?
[is this a small, standalone "pkg-get" thing that gives users
and admins access to a larger set of components for their
OpenSolaris systems, or is it a larger environmental sea change
that impacts the way that OpenSolaris is developed, built, tested
and delivered?]
3) Does it actually work for the use cases and scope called out
above?
[If (as it seems), you intend conary to be used as a replacement
source code management, build management, repository management
and publication mechanism for all of OpenSolaris, do you have
proof that it actually can do that job? One of the things that
is taking the IPS project so long is that it is actually trying
to use itself to construct a complete OpenSolaris distro. We
asked this same question when we evaluated bitkeeper, svn and hg.
Can conary do as much?]
4) How does it deal with the existing solaris/svr4 packages, patches
and admin-facing interfaces related to them?
[not might or could, but does. Any proposal to replace pkgadd and
patchadd needs to deal with their legacy.]
5) What is the relationship between this project and the others being
done in the install/packaging CG? This sounds like a design choice;
what has the CG itself said about it? ... have you asked?
Finally, why the seemingly frantic effort to force a confrontation
and/or decision? ABICT, your project has been dormant since Oct 11,
and you only came up for air today to diss the distro CG and the IPS
Project....
-John
