As part of my work on autopackage during the week, I'm hoping to develop a packaging system that is a bit more flexible than RPM, ie would allow user interactions and such. For now though, it's still a long way off, so we'd need to allow Wine installation to be completely automatic.
It seems that the ./tools/wineinstall script will need to be modularised somewhat, perhaps split into the compilation stage and the setup stage. Setup would right now just be a script that creates the initial fake windows drive and imports the registry, later it could be extended to dynamically set up certain elements of the registry, for instance:
- NIC info (read from /proc?) - Proxy data (read from gconf2 in gnome2 or environment variables) - Language settings (env vars) - ????
Writing scripts to do this is probably easier than adding registry code, so I'll get started on doing that split sometime next week, if people are happy with that plan.
On Fri, 2003-04-04 at 07:30, Maxime Bellengé wrote:
Maybe a little bit off topic but I think it is interesting.
I am working on kernel32 LanguageGroups functions (patch soon) and they need some registry entries to work. As the registry keys are language dependent, it could be great if they could be set at install time according to the will of the user.
Max
On Fri, 2003-04-04 at 00:05, Alexandre Julliard wrote:
Mike Hearn mike@theoretic.com writes:
Install time is an extra step that would increase packaging complexity.
We will need a way to create the initial registry anyway, 'regedit winedefault.reg' is clearly not enough, we need to do the dll registration etc. So it can be added there.
Wine startup would hit startup time. Perhaps, check if the keys exist at startup and if they don't, create them? If the network config changes perhaps a small winelib app that recalculates the keys could be used - tying into kernel notifications could come later. Would that be OK?
You should be able to do that with a script that calls regedit IMO, no need for a Winelib app.