On Tue, Sep 16, 2008 at 6:03 PM, <[EMAIL PROTECTED]> wrote: > Just adding my $.02, since I'm actually the one doing most of the > transport work. Shawn has made most of the relevant points already, but > I'm going to expound upon a few. > >> > The correct approach would be to eliminate the repository/depot and >> > just make packages be files that are put someplace. Whether that be a >> > web server, ftp server, nfs server, CD, usb stick, or local disk is >> > immaterial. > > I think you're confusing the correct approach with the approach you find > simplest to comprehend.
It's not about my simplicity of comprehension; it is absolutely all about lowering barriers to entry and enabling widespread deployment. > I haven't read any articulate objection that > indicates we made an incorrect choice when favoring network install. Allowing it is good (but not necessary - it's not hard to script wget on top of a package system that isn't itself network aware). Excluding other delivery mechanisms is bad. >> Packages are just essentially files that are put somewhere right now. >> It's just that the all the individual files of the package are put >> somewhere instead of a single file. Once package dependencies and >> grouping has been redone properly, users will benefit from reduced >> bandwidth usage and I/O. > > Users already derive some benefit. When we perform an upgrade, you only > download the files that have changed. Other packaging formats require > that you download an entire package with all of the files, changed or > not. That's exactly what I want. I want to grab the whole thing. That way I just have to grab one thing once, and can grab it via any means I like. I don't want multiple machines repeatedly grabbing a subset of the package. And I want the whole thing on my disk so I don't have to refetch it in the future. >> > The current mechanism is a huge barrier to entry. Not only does it >> > make it much harder for other sites to distribute your software, it >> > makes it enormously hard for end developers who wish to distribute >> > software for OpenSolaris. If, and this will be the common case, they >> > aren't able to run their own repository then they can't create or >> > distribute OpenSolaris packages at all, which harms the whole >> > ecosystem. > > We aren't stopping anyone from running their own repository. Not directly, but running a repository is going to be difficult or impossible in many cases (there's no way I can do it with my hosting provider, for example). Sticking a package as a file on a network attached server (or media, or whatever) is going to be possible for anybody anywhere, and that's the sort of low barrier to entry that we need. >> > This is why the on-disk package file format is the crucial piece of >> > the puzzle, because that should be the form in which the software >> > moves around. >> >> I don't know why you insist that can be the only form that software >> moves around in -- it's certainly a valid form, but not the only form in >> my view. > > I agree with Shawn. There's no reason why we need to insist upon only > one way in which the bits get moved around. I'm not. The current depot system does. I want a system that allows anyone to create, distribute, and use packages in any way they choose, without having to do it just the one restricted way. >> To quote j: >> "The download format is going to be changed as part of other transport >> work. Our intent is to move away from tarfiles, and instead have >> clients perform pipelined HTTP GETs." > > And once we get to that point, we should be able to remove what little > logic remains in the depot for downloading files. The goal is to have > the download front end be interchangable. You could use Apache, > CherryPY, your HTTPd of choice, or even FTP or file. As I understand it, that's only for the data part. You still have to have a primary server, which doesn't solve the main problem. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
