...
| 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.
If IPS provides clusters (in future), the problem of packages being too
thin may be a non issue. (use the cluster instead for the app that you want
to install.)
| 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 would like to suggest having a central package per cluster for things
of that nature. (I might want to turn the php support on and off in
apache with out messing with the php support of - say lighthttpd)
so that rather than modify the httpd.conf on installation, it can wait
for the user to enable it. (and disable it if needed)
| 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.
...
| > 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.
rahul
--
1. e4 _
