Dave Miner wrote: > Jordan Brown wrote: > ... >> I was under the impression that one of the goals of IPS was to >> eliminate the need for external installers. >> > > I think much of the issue in this thread is that the impression you're > stating here is incorrect. While there are IPS slides that say > something like "get rid of installer magic", that statement was made, as > I recall, in direct relation to how dependencies and groupings were > handled (especially in relation to upgrades of software), not in > relation to all of the possible configuration operations that are > required to make complex software systems initially work, which is of > course what is commonly referred to as "configuration".
If that's the intent, I suggest that those slide decks be corrected. However, ... > Conflating configuration with package management is bound to be a > mistake, pure and simple, because then the demand for complexity in the > packaging system grows without bound. The fact that the one product > installer that's been released based on IPS (Caiman) is much simpler > than the one it replaces has much more to do with our explicit decision > to eliminate or defer configuration steps than with anything IPS is > providing. The approach that the UC wiki links that Tom provided seem > to be right on. I split "configuration" into two very distinct types: Those operations that are purely mechanical and identical for each system - importing SMF manifests, adding X fonts to fonts.dir files, adding entries to system-default Gnome menus, and the ilk - and those operations that require human interaction to set site-specific parameters. Attacking those two separately... I contend that software installation and software removal are incomplete unless they include the mechanical operations required to plug the newly added software into its infrastructure and, more critically, unplug it before removing it. (It may be possible to lazily plug the software in after installing it. It's a great deal harder to lazily unplug the software before removing it.) Yes, you can wrap all this into some higher-level tool like this Update Center. (BTW, this is going to be very confusing for those of us who worked on Update Connection.) However, the net result is that you _must_ use that higher-level tool; if you attempt to do raw "packaging" operations then you will damage the system. That's fine, as long as everybody understands that the raw packaging operations are not for human use, that they bear approximately the same relationship to the overall installation process that "cp" and "rm" have to the packaging process. If that's the plan, that's probably fine with me... just tell me how to plug into that higher-level framework, and promise me that I don't have to support direct use of the package tools. The other type of configuration is the type requiring human interaction, where a human must be involved to specify parameters that are required for even the most basic operation of the software. Perhaps that can be done entirely through the application, the first time that the user executes it, or perhaps not. If the application is not normally interactive - if, for instance, it's a server - then it'll be necessary for the user to explicitly invoke its configuration user interface. That's fine, but if the installation is being done in an environment where a user interface is available, the installation should lead seamlessly into the configuration UI. As for simplicity, well... the rule is "as simple as possible, but no simpler". The complexity doesn't go away[*]. It just moves. If you want simplicity at any cost, why not just use "wget" and "unzip" and "rm"? They get bits installed pretty well, as long as you don't care about unnecessary complexity like dependencies and automatic uninstall. [*] Deferring post-installation operations on non-running roots to the next boot does make many things simpler, and may well be an overall win. (I'm less clear on how removal fits into that picture.) However, that's not the same as eliminating those operations entirely. There needs to be a structured framework, part of the overall software installation lifecycle, that handles those operations in each of the install scenarios. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
