Ticket #420 (assigned task)

Opened 2 years ago

Last modified 7 months ago

DLL Hell prevention

Reported by: hrachovv Assigned to: klattimer (accepted)
Priority: blocker Milestone: 0.2 - the refactoring
Component: Core Severity: catastrophic
Keywords: Cc:

Description

During writing deinstallation scripts I've stumbled upon the DLL hell.

All packages

  • dcom-98
  • ie-6.0.2800.1106
  • vb_runtime-5
  • vb_runtime-6
  • vc_runtime-6

provide OLEAUT32.DLL (and more).

We should provide some mechanism similar to dpkg-statoverride:

  • when there is a need to overwrite (within package installation) already existing file belonging to some package, the old file should be backed up into preferably filename.ext.package_name
  • upon deletion of the filename.ext (on package removal), its files (non-backed up) should be erased
  • package backed-up files should be erased
  • package files which are occupying the default place filename.ext, when some other files in directory exists with the same filename.ext.* prefix, should be removed and replaced with the first 'waiting' DLL

Without such functionality we're going into serious troubles when uninstalling some application can break the complete installation to unusable state. This could lead to usage of wine-doors as 'install-only' tool.

Attachments

Change History

02/28/07 13:45:13 changed by klattimer

  • milestone changed from 0.2 to 1.0 - Business Enabled.

This looks like a job for the inotify install watcher i'm planning. Until then we'll have to come up with some uninstall hacks

03/26/07 16:28:51 changed by klattimer

  • milestone changed from 1.0 - Enterprise to 0.9 Bottled and profiled.

04/24/07 09:23:56 changed by klattimer

An interesting way to fix this is to have a new list index in the installed list, for instance

<sharedlib>oleaut32.dll</sharelib>

Upon uninstall, of one of those applications wine-doors would then scan the installed list for other applications which provide/depend on that shared library, if any are found remove from that list of dependent apps any matching apps from the queue. If after the dependent apps have been trimmed with other pending uninstalls, the dependent apps list has no members, the last application in the queue to use that shared library will remove it from the system.

This seems like the cleanest solution. It could then also become a tag in general packlists, as part of a provides/requires list of sharedlibs. This would improve the granularity of the dependency resolution also

05/08/07 04:50:59 changed by klattimer

  • milestone changed from 0.9 Bottled and profiled to 0.2.

Moving this to 0.2, should be much easier to fix by then.

06/10/07 05:45:26 changed by klattimer

  • milestone changed from 0.2 - Lots more apps to 0.3 Bottled and profiled.

07/05/07 13:54:02 changed by anonymous

American architecture in its landscape maker penn study villa vizcaya History of modern art painting sculpture architecture photography

07/05/07 15:32:20 changed by anonymous

wine cabinet wine gift set

12/08/07 17:25:17 changed by klattimer

  • milestone changed from 0.3 - Bottled to 0.2 - the refactoring.

02/08/08 10:33:15 changed by klattimer

  • priority changed from critical to blocker.
  • status changed from new to assigned.

02/08/08 10:33:50 changed by klattimer

needs to be merged into 0.2 XML examples?

Add/Change #420 (DLL Hell prevention)