The installer should delete the old registry

[GoogleCodeExporter]

I opened this issue to keep track for a future release.
The gstreamer's registry is usually invalid from one release to another and
needs to be regenerated. The installer should delete the folder
.gstreamer-0.10 folder  to force a rebuild of the registry

Original issue reported on code.google.com by ylatuya on 24 Apr 2010 at 6:59

[GoogleCodeExporter]

I'm a bit unsure about this one. I sorta agree, but then again, gstreamer is 
supposed to be able to handle changes and automatically update the registry 
accordingly. If it's not, wouldn't that be a bug?

Original comment by david.g.hoyt on 24 Apr 2010 at 7:23

[GoogleCodeExporter]

I don't that much about the registry and I don't fully understand why this 
happens. I
think it's a mix between GStreamer and GLib and I don't know what should be 
fixed :/
(gst-inspect-0.10:3492): GLib-GObject-WARNING **: cannot register existing type
`GstMMS'
It's like if the internal structure of the plugin changes and therefore the 
gobject
type changes, glib doesn't recognise the registered object type anymore.

Original comment by ylatuya on 24 Apr 2010 at 8:17

[GoogleCodeExporter]

The main problem w/ doing this is that we don't know which accounts to delete 
the 
registry file in and which not to. If a user installs the software as an 
administrator but runs it under a normal user account, do we look in both 
places? 
What if there are multiple people using it on the same machine? What if their 
account is on the domain and their home directory is roaming? There are too 
many 
issues there and that's why the MS installer guys tell you not to design your 
app 
that way.

I've asked how to do what you're proposing (b/c I had the exact same idea 
myself - 
I'd like to eliminate the issues w/ people accidentally mixing an old registry 
w/ 
the new install) on the WiX mailing list and the response I got was not to try 
or 
it'd have to be done using a custom action.

Perhaps instead we could write an enhancement in the registry code that 
determines 
if we're loading a plugin w/ a created/modification date greater than the 
registry 
file's, that it's time to recreate it from scratch.

Original comment by david.g.hoyt on 24 Apr 2010 at 11:53

[GoogleCodeExporter]

Of course this is not going to cover the corner cases, but at least it will 
temporary
solve the most basic case. I'll ask on irc for some suggestion on how to solve 
this
issue.

Original comment by ylatuya on 25 Apr 2010 at 6:10

[GoogleCodeExporter]

I have talked with wtay ragarding this issue and he told me that the registry 
updates
any new plugin based on the .dll file timestamp. So it's definitivly a Windows 
bug
that we should be fix.
I'll take of it.

Original comment by ylatuya on 14 May 2010 at 7:09

• Changed state: Started

[GoogleCodeExporter]

Increased the priority since it's causing many troubles to many developers and 
should
be fixed ASAP

Original comment by ylatuya on 14 May 2010 at 7:10

• Added labels: Priority-Critical
• Removed labels: Priority-Low

[GoogleCodeExporter]

A *possible*, although ugly, fix (if your fix doesn't pan out) might be to use 
the
GST_REGISTRY env var and in the install point it to <Home
Dir>/.ossbuild/v0.10.6/registry.bin

By doing so, with every new install, it would recreate the registry from 
scratch.

I admit it's a very ugly solution and suboptimal (at best) and it would leave a 
bunch
of old registry files lying around after several version installations. But 
it'd work. :/

Original comment by david.g.hoyt on 14 May 2010 at 10:44

[GoogleCodeExporter]

That'd be an excellent solution until we properly fic the registry stuff.

Original comment by ylatuya on 15 May 2010 at 1:51

[GoogleCodeExporter]

Should we implement this? I think having a registry with a path based on the 
core version can be useful.

Original comment by ylatuya on 3 Oct 2010 at 1:39