I got an answer :D oiaohm wrote: > Fix the bug of bugs first. liberavia > > "Wine does not support multi user install. of applications." > > Basically fix is core issue of wine. Would allow global installs of applications into prefixs shared being users. > > Problem is its not a simple bug to fix. It means implementing users in wine. > And because its not simple fixing this, i think about creating workarrounds like teamviewer or picasa does. Have you looked the bash scripts of teamviewer for example? wine + app lies in opt. The menu entry which is created while the installation (postinst) of the package, calls a start script which creates (if not done yet) a structure of the app into the current home folder, including reg's and symlinks pointing to the wine install in opt which it is delivered with the package. Couldn't that be a good way to deal with the core problem? oiaohm wrote: > > Native porting of applications is always better than even doing this. liberavia > Full ack, but you know that this is a "chicken or the egg" dillema. And if a certain app runs fine with a certain wine-version, why not pack them together as a working unit. oiaohm wrote: > > Security issues are not addressable by apparmor or anything else for share multi user installs. Wine design has to be corrected so they can do their job. Basically secuirty takes us back to the bugs of bugs doing this. > Currently I don't feel be able to solve the core problems, but i feel being inspirated to work them arround, and try to minimize them as good as I can. oiaohm wrote: > > Performance issues don't get better or worse dependent on the numbers of wine running most of the time Wine is heavier than native program doing the same job. Different versions add load. But wine does support multi versions of wine installed. Packager insist on installer wine is a format that only supports 1. Its not required. > Its clear that it produces more load then it would run natively, especially if there would be multiple instances of wine. I hope I got your last sentence right, but if we look on the teamviewer package-dependencies, you won't find wine at all. [quote="oiaohm"] There is no valid reason to put a copy of wine with every application. Ie make package dependent on the version of wine it requires and have that installed. Save disk space. Really a 3 package design would be wise. 1) Wine package ie containing wine it self. 2) Application and data package 3) Wine version selection package and reg's for the application and start menu entrys. This could also contain wine version particular tweaks for the application. With dependencies 3 can trigger the install of the other 2. Also its possible to have this without 2 as well. This way when application is found to be able to run with newer wine. Only the small joining package would have to be downloaded. [/qoute] I would say this would be an optimization issue. My example application wich i want to use for my experiments has 8 apps included, so it's clear that i would generate a package like apname-winelayer and a single package for each app which are depending on this layer. oiaohm wrote: > > Licensing question is simple. Don't have the installer in the deb for unsupport instead have it ask for the disk/media just like quake2 and on of the quake games do for getting the game data from the demo. And have a way for end user to wrap binary in if they are legal owner for major deployments. No license troubles. Yes 3 package design does make doing this simpler. Games are a special issue and currently not in my mind. If a game should be ported this way you would also put the library, graphics, sound etc in a single package. Currently I'm more focused on apps that are used in my company and prevents me from switching to linux-desktops. Gert van den Berg wrote: > > AS far as I know, the Linux version of Picasa does something like > this? (Not sure how its packaged) > Great I will have a look on my hopefully second example :) . Regards
