compreg.dat, xpti.dat in install DIR (Re: Bug#426569: Fwd: Bug#426569)

[Mike Hommey]

On Wed, May 30, 2007 at 03:08:40PM +0200, Alexander Sack wrote:
> On Wed, May 30, 2007 at 11:07:19AM +0200, Mike Hommey wrote:
> > On Wed, May 30, 2007 at 10:36:06AM +0200, Alexander Sack wrote:
> > > Do you know of a use case where it makes sense to create those files in
> > > the install directory? If not, is there an upstream bug/fix to not
> > > create those files?
> > 
> > The only I know of would be to speed up startup time for applications that
> > don't store these files in the user profile directory, which seems to be the
> > case for epiphany, which I'm quite surprised, actually.
> > 
> > Actually, it could make sense to generate them though I'm not sure yet what
> > I might choose. The one thing that could be useful, though, would be to
> > invalidate in memory what is read from these files when the autoreg file is
> > newer. What seems to be happening (from my reading of an strace) is that it
> > tries to write a new set of files and then read from them. Except that when
> > you're not root, you can't write there. The old problems with the assumption
> > that mostly anyone can write in the application directory...
> > 
> > I might try to fix this in the long term, but the shorter term will be to
> > just remove the files in the postinst.
> > 
> 
> To fix this we should add the cases for COMPONENT_REGISTRY and XPTI
> keys to GTKEmbedDirectoryProvider::GetFile
> (embedding/browser/gtk/src/EmbedPrivate.cpp)

There is no such thing on the 1.8 branch.

> ... I will try to reproduce and then fix this.
> 
> The other option is to make xpcom core aware of profiles et al ... but
> I don't think its the way to go.

That is not possible because not every xpcom application support nor needs
user profiles.

Mike