On Wed, May 14, 2008 at 04:26:50PM -0700, Jordan Brown wrote: > They expect a near-seamless process that starts with media or a URL and > ends with a working application, usable for productive work.
There's nothing we're doing that prevents people from writing installers. That's what an installer is for -- providing a complete soup to nuts installation and configuration experience. A packaging system is just for laying down the bits (the soup, I guess). > Suppose for a moment that SMF was a legacy component I'm not sure if your point here is to pick some random subsystem into which we want to install some bits, and that doing so might involve frobulating files, rather than simply putting files down, or whether, if SMF weren't what SMF is, wouldn't be SMF. I'll assume you meant the former. Which means that SMF is what it is, and provides a perfect (arguably) mechanism for doing the frobulating, as it provides a known context, and offloads application-specific knowledge into that context (i.e., the shim you talk about). > Suppose that the manifest that was delivered is malformed, or is in some > application-specific way incompatible with the existing manifests. How > is this failure reported to the user? Sure, it's not a *packaging* > failure, but it most certainly is a *deployment* failure, and it needs to > be reported to the user in the context of the deployment operation. Sure. So if you're installing onto a live root, your nifty installer can check if the service(s) in question is in the maintenance state and do appropriate analysis if it is, reporting to the user. If you don't have a fancy installer, then svcs -xv should be one of the first things you look at if software isn't working on the system. Perhaps "pkg install" could let you know what services it's pinging so that you can wait for them to come back online. On the other hand, if you're not installing on a live root, then there's simply no way to check if the deployment worked until you've rebooted. Any solution you come up with *has* to deal with that scenario, and really needs to have the same architecture as the live-root case, though we may be able to provide some shortcuts for live-root. > Should I come up with a list of thought experiments, of relatively > realistic installation scenarios, for you to explain the IPS-correct way > of delivering the software? Feel free to share, though I'd like to see Bart's first cut before we get too anxious about the more complex cases. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
