Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
That'd be an excellent solution until we properly fic the registry stuff.
Original comment by ylatuya
on 15 May 2010 at 1:51
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
Original issue reported on code.google.com by
ylatuya
on 24 Apr 2010 at 6:59