On Feb 9, 2008 1:43 AM, John Plocher <John.Plocher at sun.com> wrote:
> 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? My understanding is that ARC is the forum for guidance, as well as informing the community of intended projects. Is this the wrong mailing list? Do I need to send this to psarc-ext? Also regarding alternate packaging systems, please see the conary-eval project page, as we do touch on them: http://www.opensolaris.org/os/project/conary-eval/ 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?] It has been indicated that network repository based packaging efforts are desired. I am open to apt-get and even extending system v packaging. We as a community must however understand what we wish to accomplish. > 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?] You will be happy to know yes, and yes. It can in fact coexist with system v packages, and could be adapted to use an /opt/conary type of SFW tree. If you are rather looking to package up the entire OS, it can do so. It does not require a change in the way OpenSolaris is built, as it can be used as a binary packaging system that takes existing development trains and repackages them for alternate consumption. (However it does also support changing the way the OS is built, *IF* that is desired. (It is a lot of work, that may, or may not be worth the effort.) > 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?] What sort of proof do you need? We are coming to the ARC early, prior to having a finished project, just as you, and others, have suggested on many occasions. We went through a lot of pain just trying to figure out if a port was possible. We very recently cleared certain hurdles that convinced us this will work, giving us the confidence to seek further advice. 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.] Agreed. How should any prospective packaging system handle legacy SVr4 packages? You say "not might or could but does", yet at the same time you say to "ARC, early and often". Consider this an early ARC review request which we plan to often update, and seek further guidance. > 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? I was told by Stephen Hahn that Conary had been evaluated for use but was not being considered because of proprietary Sun business reasons which could not be shared with the community. (And some technical reasons, that upon further reexamination are not actually mandatory. IE: Conary does on not force a build system on package maintainers). After reaching an impasse there, we got a project "reluctantly" approved to officially explore conary. (But were not allowed to have our own mailing list). After a many month review, we still don't know what the business reason(s) behind rejecting Conary could possibly be. (Frankly, Sun business reasons should not effect the OpenSolaris.org technical decisions, but we are not against accomodating our sponsors, if the argument makes sense. Since all the planning happened behind Sun firewalls, we can only guess, what the "Sun business reasons" are.) 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... This is a request for guidance from the OpenSolaris ARC (Architectural review committee). I do not understand why you are attacking this request? Again, I ask for ARC guidance, not a "decision". (Please define ABICT? Google was no help.) Also, you will see the project actually has not been dormant since Oct 11. The project page has been updated on numerous occasions between Oct and now, it's just that because we didn't know if the Conary was even going to be technically possible until very, very recently, so there was really no point in sharing. (IE: What point is the evaluation, if it can't be used.) Finally this request for guidance from the ARC is not a "diss" of anything. Hopefully, as a result of this the OpenSolaris community will be able to come to a comon set of requirements that any packaging system must meet. (Or be adapted to meet). As I am aware there are no other proposals before the ARC for guidance in creating or adopting an OpenSolaris packaging system. Please understand, that unlike many other packaging efforts in the OpenSolaris/Solaris technical sphere (pkg-get, apt-clone/get, rpm, pkgsource, ips), we seek to work within the guidelines of the existing ARC, and are trying to follow the guideline "ARC early and ARC often". (Unless I am misunderstanding "how things get done around here"). We are currently working with the IPS folks to try and understand their design criteria behind IPS now. The fact is packaging and install became a very complex issue, with the introduction of zones and smf. (As I'm sure the IPS folks will attest to.) One observation right now, is that many of the requirements for IPS seem to be very SMI-centric, and as external community members, we can not always fully relate. (As certain "requirements" make little sense within the scope of the externally facing realm of OpenSolaris development). Thanks, Brian > > -John > > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ http://www.genunix.org/wiki/index.php/OpenSolaris_New_User_FAQ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20080211/7cb63ac9/attachment.html>
