(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.
>>> 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. > > 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. >>> 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. > > 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. >>> 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. > 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) >>> 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. > And even in this case it's much easier to use custom-build packages, not just binaries. >>> 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. > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
