Stephen Hahn wrote: > * Joseph Di Pol <[EMAIL PROTECTED]> [2008-05-22 06:08]: >> Stephen Hahn wrote: >>> * Tom Mueller (pkg-discuss) <[EMAIL PROTECTED]> [2008-05-21 14:20]: >>>> With GNOME and a non-root user, doesn't the file have to be >>>> installed under $HOME/.gnome somewhere? This directory is >>>> typically not going to be within the user image so a simple >>>> install of a file doesn't work. Also, if the same application is >>>> installed three times in different user images by a user >>>> (slightly different versions), there needs to be some resolution >>>> regarding multiple menu entries. On Windows its a whole >>>> different story with registry editing, etc. >>> This expansion starts to suggest why this use case is confused. >> Well, it's a real use case, so I rather like it. > > Okay: I believe Tom's question about multiple menu entries is yours, > then. > >>> It leads me to the question of when does an installation into a user >>> image affect a particular resource outside that image? The safe >>> answer is never, so what exceptions do we feel have to be made? One >>> aspect of the menu items that bothers me is from the enterprise >>> developer scenario: >>> >>> - tools master A creates user image with stack 1.0 >>> >>> - tools master A gets menu items? >> Yes! And he is thrilled. Especially since he not only gets >> menu items, but a toolbar notification when new updates are >> available for that user image he is managing. > > The notification is clearly coming from other software on the system. > Why couldn't that software also do the "outside the image" > installation?
Actually the startup task we want to register may very well come from within the user image. > >> Menu items and a startup task are a real use case we must >> deal with. So I'd like to stick with it. >> >> Keep in mind a large number of our users will be developers on laptops >> (or self-managed desktops). We want to optimize the user experience >> for them. > > Okay, but those people don't need to have N installs of different > versions in separate images. That's the enterprise case, which is > separate from the developer case. Our project believes developers want this too. > For instance, on OpenSolaris, I expect these tools/servers to be in > pkg.opensolaris.org in such a way that I, on my laptop, can pkg > install them, and they go into the correct location and have smf(5) > services registered, etc. Yes. That's consistent with an OS distribution point of view. Our point of view is slightly different. Over the years we have had consistent feedback that customers want non-root install and multi-install. That's why so many of our products offer zip based installers as a very popular alternative to native packaging. > > (If your laptop use case has each piece of software in a separate > image, that's probably suspect.) We don't have each piece of software in separate user images, but we do have each installed instance of a "consolidation" in a user image. Where a "consolidation" is roughly the granularity of a Java ES Suite. >>> (As an aside, one intended aspect of user images *is* to allow a >>> user's home directory to be a user image. That makes delivery into >>> $HOME/.foo straightforward.) >> But (in our case) it often won't be. And as other folks have >> stated we need to deal with systems that may not support just >> dropping a file in a directory. > > If that file goes outside the image, it's not really a packaging > action. So far, I've only heard an attempt to shift such operations > back into packaging--why aren't these installer layer > responsibilities? Like I said in my original post we are already handling this at the installer layer, but we feel it would result in a better user experience if triggered by IPS. Joe _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
