Jyri Virkki wrote: > rahul wrote: > >> | Which leaves mod_security, does it have any interesting dependencies? >> >> It just has pcre which we already have as part of the SXDE. >> > > What I'm looking at is not whether it's available (well, it has to be > available for the build to work so it's a given!) but whether it is a > dependency that pulls in unwarranted (for some users) packages. For > the SXDE distro that's largely irrelevant since it is one big DVD that > throws everything onto disk anyway. >
This isn't quite accurate. The SXDE installer throws everything on the disk, but the traditional installer is still there with the ability to select packages, as are jumpstart installations. How you obtain the package (via the DVD or the a pkg(5) network repository) is orthogonal to whether or not the user decides to install a Sun package cluster. Having said that, IPS will put this right in the face of the end user, so the poor packaging (too tight or too loose dependencies, packages too fat/thin) prior to IPS cannot continue and still hit IPS goals. > But later with IPS when I get to pick only packages I really want, > it'll be important to avoid bringing in large chunks of functionality > not everyone might want (e.g. installing apache shouldn't require > installing, say, postgres, because not everyone who wants apache > always wants postgres). > One thing I'd asked David Comay about with IPS, and he said had been considered, is some sort of meta-cluster like functionality. This is important because the permutations with which these web stack components and their extensions can be wired together is seemingly endless. I don't think we can provide meta-clusters for all of the permutations, but certain popular combinations (like A+M+PHP and A+PostgreSQL+PHP or A+Ruby+MySQL) should be considered. Asking the user to correctly find all of the individual packages would probably be frustrating, but making them strict dependencies and installing too much because we don't know what run-time dependencies they'll actually use would be equally frustrating. One concern here, with pkg(5) being a no-scripting zone, something I do agree with the design goals of, we may be left needing to consider a post-install configurator or something of that sort. Asking the user to edit the httpd.conf/php.ini and know what to turn on in order to get, say the postgres extensions turned on is something that would need to be handled. I believe it would be impractical to make major changes to get the upstream projects to work with SMF to describe how to wire things together, though that would probably be the preferred approach with pkg(5). I think I may have mentioned that Joe DiPol and I talked about what Java ES is planning for, and that's their approach. They have this meta-cluster kind of issue too, as you may decide to install Portal with Web Server or Application Server. > For smaller common libs like pcre it doesn't seem like a big deal even > if I don't want pcre. Admittedly the line is a bit fuzzy here.. > > >> There is a caveat involved in adding all to SUNWapch22u, If we plan >> to allow users to compile the sources directly in their machines >> (like FreeBSD ports) then a breakage in any of the dependent sources >> can break the entire source build. Thus if there is a build break >> in mod_jk, it will break apache22 too. While this is not a concern >> right now, I think it should be considered because of the future >> impact. >> > > Yes and if ruby build breaks why should postgres nighly build be > busted (not to pick on ruby ;-)... you're right, the current huge > consolidation model doesn't really work and will crumble under its own > weight soon. But... solving that will take a little longer. > While I agree it will take a while to solve, I'd hope we could at least get the SFWNV Open Source consolidation outside the firewall as something other than a regularly uploaded tarball..... :) > But for the above example, I wouldn't mind so much if things like > apache and apache modules are closely coupled at built time since > these are tightly related functionality anyway. > By the way, this is one of my frequently picked-nits with blastwave.org. I really like the work they've done over there, and I support them (though Phil Brown and I may not agree on the pkg stuff), but they too suffer from some of the package dependency issues. For instance, if you get Apache, it usually pulls down OpenLDAP, which then pulls down all of it's dependencies (bdb), etc. I suspect it's there because of the build-time dependency, which is very different than a run-time dependency. - Matt -- Matt Ingenthron - Web Infrastructure Solutions Architect Sun Microsystems, Inc. - Global Systems Practice http://blogs.sun.com/mingenthron/ email: matt.ingenthron at sun.com Phone: 310-242-6439
