On Wed, May 14, 2008 at 12:27 PM, Alexander Vlasov <[EMAIL PROTECTED]> wrote: > (sorry for overquoting, but seems it matters in this thread) > > Shawn Walker wrote: >> >> On Wed, May 14, 2008 at 10:22 AM, Alexander Vlasov >> <[EMAIL PROTECTED]> wrote: >> >>> >>> Shawn Walker wrote: >>> Well, OS installation itself can be split in two big parts: everything >>> but >>> packages installation and packages installation. Second part is exactly >>> the >>> same as in regular package installation. Returning to the very first >>> post, >>> the point is -- if you can separate package delivery and package >>> installation, it would be easier to introduce new installer(s), because >>> you >>> should only change one part out of two. >>> >> >> I don't disagree with that. That's why I'm interested in distributing >> mini-repositories as the delivery format. >> > > Oh god. Finally I got your idea about micro-repos. It sounds like big > improvement over current ips approach, but comparing (ips+minirepo) vs. > traditional package-as-file, I'm still not sure that new approach is better. > We're losing per-package granularity, but I can't see what we're getting.
You don't really lose per-package granularity in the strictest sense. In other words, there's no reason why a mini-repository can't contain a single package. There's a few things that distributing a repository instead of a package solves in my mind: * Finding satisfiable dependencies * Avoiding package format issues * Ease of serving packages via almost any protocol My personal, eventual goal is to create a prototype that lets you have nothing but the files for the repository sitting *somewhere* (think /var/my_repository, or http://host.name/repository) and the client would be smart enough to grab everything from the server and install it without any special software required on the "server-side". For example, I would love to see: pkg -d /var/repo_dir install SUNWfirefox or pkg -d http://random.akamai.cache.server/repo_dir install SUNWfirefox ...and have it grab everything it needs from the indicated location. Likewise this would allow you to put a collection of say, network drivers, on a USB flash device and you could do: pkg -d /media/flash_device list -sa To see all the available packages, their versions, etc. Or you could easily do: pkg -d /media/flash_device search file_to_look_for Something like that anyway. To me, that is a marked advantage over the current process today where a user downloads several packages files into a directory like this: neatprogram.pkg, baz.pkg, bar.pkg, foo.pkg Then they're left to figure out how to get that to install. With many systems, they also have very limited query or other capabilities until they install the package. So having a "repository" of neatprogram, baz, bar, and foo could provide a lot of nice additional functionality. I believe it would even be possible to have: my_repo_tarball.tgz pkg -d /path/to/my_repo_tarball.tgz install SUNWfirefox ...and have it automatically handle the rest. >> If you're applying all of this to "things as they currently are", yes >> I'd agree to a certain extent. >> >> > > I have no tools but those which do exist right now. So either current tools > should be good or there should be a clear goal to design and implement other > set of tools, IMHO. There are lots of entries in Bugzilla about meeting various needs. I'd encourage you to file enhancement requests for any of the gaps. >> I don't disagree that packaging is important, but I still don't see >> the necessity of the build system being part of packaging. >> >> > > If we're talking about package build system (not binaries build system), it > should be a part od packaging system because it does two-step transformation > source code -> binaries -> correct package. First step is > application-specific, second one can be reasonably general and > contet-agnostic. I'm talking about second one. > It is only related to the packaging system. If you're just talking about a way to re-arrange the binaries into a format for a package, that's what the depot server does right now if I understand you correctly. In that case, I think I could still apply my personal idea of being able to create mini-repositories easily to do that. >> Having a build system being part of the packaging system is not a >> guarantee of the resulting package quality, nor does it in my view, >> greatly benefit packaging quality. >> > > Unified process will 1) reduce the amount of dummy mistakes 2) make fixing > process much easier (just modify what needs to be modified and rebuilt your > package with one command) It depends on which build system you are talking about. Compiling or creating packages? -- Shawn Walker "To err is human -- and to blame it on a computer is even more so." - Robert Orben _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
