Sriram Narayanan wrote: > On Tue, Sep 16, 2008 at 10:03 PM, Stephen Hahn <[EMAIL PROTECTED]> wrote: >>> The client does not seem to be that lightweight. It has to do a >>> bunch of processing checking package revisions, processing metadata >>> and generating package plans which are non-trivial computations. >>> I'd tend to think that the processing load is being balanced 50-50 >>> between server and client. It should be possible to have the >>> server-side component being done by the client as well without >>> functionality loss. >> The client is not going to become lightweight; your CPU processing >> estimate is not accurate (nor realistic, if one thinks about scale). >> In fact, the client is doing the bulk of the work--the server is only >> handling our HTTP/1.0 workaround and the search operation. > > I believe that Moinak's thoughts are : if the search operation is > pushed to the client (like, say, with rpm/apt), then the server would > become http, file, ftp, etc without needing a custom server behind > those services.
The client already has search capability locally, so that seems a moot point. However, local search doesn't solve the problem of trying to search for things you don't even have. It also doesn't scale very well when you want to search a specific repository's contents. >>> This is fine and removes one big problem of the sparse file. However >>> rsync is still not straightforward. When rsync-ing from server_a to >>> server_b >>> the depotd on the server_b will have to be stopped for the duration of >>> the >>> rsync. Alternatively one has to maintain a duplicate directory structure >>> on server_b, rsync to that and then cpio it to the actual depot to reduce >>> downtime. In any case this some amount of round-about activity and >>> does not fit into the straight zero-complexity distribution of content >>> used >>> all over the place today. >> On a ZFS-based system, it's easier than that, but two trees and a >> symbolic link is sufficient for systems without snapshots. If one is >> only mirroring content, then you can simply rsync on top; since that's >> the bulk of the install traffic, it's the most likely to have value >> when mirroring. > > As many other community distributions, the Belenix team too intends to > have mirrors around the world. > These public mirroring sites (say, ibiblio, planetmirror, sarovar, > JAIST), would not be willing to run custom servers. They'd rather have > just rsync,http, ftp. > > Now if a depot server were to become mandatory, this would become a > problem when seeking mirroring hosts > > Yes, one may say that convincing mirror hosts to run custom servers > would be Belenix's headache, but given that we've always given to and > taken from the various opensolaris technologies, we see it to > everyone's advantage if we had a discussion first before going > elsewhere :) As we have already responded, this will eventually be possible. We fully intend mirrors to be able to serve package content. We have several bugs open to change our transport methodology to accommodate this. >>> While in this thread, I will dare to make a few more comments which I >>> was able to recollect yesterday: >>> >>> *) Adopting an existing FOSS packaging framework and working with that >>> community would have gone a long way to boost SUN's perception among >>> FOSS communities. >> And forking from one of those frameworks might have done just as much >> to doom how OpenSolaris is perceived. > > If well discussed in an open and amicable manner, upstream > contributions could actually happen in a nice manner. Sun has a good > track record on several projects on this front, after all. ...and that process would likely move very slowly. OpenSolaris has unique platform requirements and needs that would require changes that upstream projects would be unlikely to accept. Examples of this that come to mind are: our zfs integration, zones support, license entitlement, etc. As I understand it, most of this has already been discussed over the past year or so. The short answer is that existing packaging systems don't meet our needs, and most of the existing wheels would be unrecognisable by the time they were altered to fit them. > As with everything else in Belenix, we're here to share these concerns > and thoughts with the opensolaris community. I certainly appreciate the feedback, and I'm sure others do as well. However, keep in mind that our goal is not to merely replicate existing systems or methodology. From my perspective, our intended goal is to bring an innovative, unique solution that is optimally tailored to the needs of OpenSolaris. I do not believe we could achieve that by simply "bolting on" pieces to an existing packaging system. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
