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. >> Hack for sort time? I'm not sure I follow. >> >> > > Just a typo. sHort time I mean. So should it be treated as "let's use it > while delivery-agnostic mechanism is in development" or "here is our new > depotd, now with banana flavor and apache support?" I'm not sure what the plans are. Stephen, Bart, Danek or others are the best to answer those questions. My view is that ips is an evolving prototype changing to meet the needs of the project as times passes. >> Most packaging systems, even when they have one file, are rarely >> suitable for humans. >> >> That's why package management GUIs and CLIs exist :-) >> > > for package-file approach, tool working with repo may not be aware of > packages' structure. With current IPS approach, it should be. here is the > difference. Again, this is why I'm interested in repositories-as-delivery-format. You can make a tarball out of a repository :-) >> Whether you're talking about a repository, a raw set of bits on disk, >> or a "single package file", with the appropriate tools you can check >> any of them. >> > > Not, that's not true. In IPS, package gets some of its properties only on > upload (think file...mode or dependencies). You can't build a package, check > it and upload when you'll be sure everything is OK, because until you upload > the package, it doesn't exists at all. Again, I think this is a matter of tools being available. If you're applying all of this to "things as they currently are", yes I'd agree to a certain extent. >> Yes, but again, I don't see the connection. In other words, I don't >> see the necessity of a build system being part of the packaging >> system. >> >> As long as something has *a build system* and a way to package the >> result, that's what matters. >> >> Whether I've built packages for RedHat, Debian, Slackware, >> zeroinstall, Windows (msi), or any other os you have to have an >> existing build system for the product anyway. >> >> If you can find some way to place a layer above the many, disparate >> build systems that exist together with little effort, then I'd be >> happy to see one. >> >> For now, I just don't think it is a problem worth solving. >> > > Nowadays, all operating systems do work. The only thing that matters is > amount of software user can get (and run). Personally I consider packaging > more important than anything including kernel, because there would be much > more users affected by, say, wrong firefox packaging than non-working > project(4). Without proper infrastructure, packaging will be error-prone and > problematic for all of us, including users, developers and administrators. I don't disagree that packaging is important, but I still don't see the necessity of the build system being part of packaging. >> I'm far more interested in the processes that directly benefit users. >> > > Packaging quality directly benefit users -- or make them cry. 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. >> No, source is *a* distribution mechanism for developers. It is not >> *the* distribution mechanism. >> > > Well, I think it is the way of distributing product for developers, at least > in case of opensource applications. It depends on which target audience you are talking about. I know *many* individuals (and organisations) that run binaries of their own, or from the developer, instead of using what their distribution packaged because it is much older than what is available. >> You will find very few *successful* developers that do not *also* >> distribute a binary in addition to source code. >> > > Binaries from author are pointless. regular user should use package, > enthusiast should use source. Binaries from the author are not pointless. Especially when you have a stable, guaranteed environment like what we have with OpenSolaris/Solaris. > Who is responsible for security support of > developer-built binary? Who tested it on particular distribution? The developer, if they're providing the packages. >> In short: >> >> * I don't believe that the idea of repository-as-a-package has been >> explored enough. >> > > Hm. I'm talking about package-as-a-file. So was I. I just don't think it's necessary if you can have repository-as-a-file, since the repository can contain the package(s). >> * If the point of ips was to simply duplicate whatever RedHat or >> Debian did, what would be the point > > Not duplicate, but accept best practices. If you haven't noticed, linux is > THE un*x-like operating system nowadays, and its ecosystem is somehow > similar to jungles. Bad ideas die quickly, so after 15 years of evolving Yes, I have noticed. I've been using GNU/Linux since 1994 or 1995. > most of ideas are very reasonable, and it would be better not to duplicate > efforts but to accept something that already works. Also it would minimize > familiarity gap and help to increase communty I must respectfully disagree. I just don't think we'll ever be in agreement over the build system aspect. However, I appreciate your candor during this discourse. Cheers, -- 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
