Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[Damjan Jovanovic <damjan jov gmail com>]

On Fri, Apr 15, 2011 at 7:45 PM, Alexander Larsson <alexl redhat com> wrote:
> On Fri, 2011-04-15 at 08:49 -0700, Kevin Fox wrote:
>> On Fri, 2011-04-15 at 06:01 -0700, Alexander Larsson wrote:
>> > On Fri, 2011-04-15 at 14:18 +0200, Damjan Jovanovic wrote:
>> >
>> >
>> > > > Of course, some files are inherently made to be external, read by
>> > > > other
>> > > > applications. Such files are hard to relocate, like application
>> > > > icons,
>> > > > desktop files, icon themes, widget themes, plugins, custom mimetype
>> > > > descriptions, dbus service files. I don't really know what to do
>> > > > with these.
>> > >
>> > > A library can discover its current path by calling dladdr() on *nix
>> > > and MacOS X, and GetModulePath() on Windows. The library then loads
>> > > resources relative to that path.
>> >
>> > Yes, thats is doable on many OSes, but its still kinda ugly, as it
>> > implies that the relative paths to the files are kept, and thus implies
>> > that things are stored in typical unix style hierarchies, etc. It is
>> > much cleaner to just have a single file.
>> >
>> > It doesn't solve the inherently hard things listed above though, because
>> > the problem for them is that *other* things than the library itself
>> > loads these files.
>>
>> Usually the tool used to solve this problem though is a file system.
>>
>> An appdir like structure is a good compromise between other things
>> needing to easily access the data and having all the stuff in one
>> location that can be easily copied and moved around.
>>
>> Another option might be to simply tar (but not [bg]zip) up the library
>> and related files and change the dynamic linker to mmap the correct
>> subsection of the file instead of the whole thing.
>
> An appdir doesn't solve the issue here. Its not that its hard to load
> the file from the relocated file that makes it problematic. Its the fact
> that the "other" app doesn't even know about the existance of the file.
>
> For instance, let us take a desktop file as an example. Applications
> typically install their desktop files in /usr/share/applications. That
> way "other" applications like the panel, the open with dialog, etc will
> find it, because they all look in that directory. There are some env
> vars you can set globally to manually make other apps look in a some
> specific other directory, but this is quite limited and doesn't work for
> random relocation of apps.

I am not sure whether you want to (1) special-case every "application"
on the system no matter where it is or if its path changes, or (2)
track "applications" once they've been associated with the desktop
somehow (eg. dragged into the panel).

The panel could remembering the inode, so even if the name changes, we
can still find it (presumably through some novel kernel API that lets
us get the path of an inode :-). If the move is across filesystem
boundaries then we're out of luck.

> The same thing happens for the other types of files i mentioned above.
> dbus looks only for service files in /usr/share/dbus-1/services, gtk
> looks for themes in /usr/lib64/gtk-3.0/3.0.0/theming-engines, etc, etc.
> So, anything that has a file of this type is "hard" to relocate.
>
> Also, apps that consume such files are also hard to relocate. Take
> nautilus for instance, it looks for extensions
> in /usr/lib64/nautilus/extensions-3.0/, but if you relocate it, how does
> extensions know where to install extensions?

These are good examples and excellent questions.

Have a look at http://replay.waybackmachine.org/20060722121208/http://plan99.net/autopackage/Thoughts_about_AppFolders
for an interesting comparison of MacOS's and Linux's approaches.

> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>       alexl redhat com            alexander larsson gmail com
> He's a scarfaced pirate werewolf on a search for his missing sister. She's a
> ditzy extravagent queen of the dead with an evil twin sister. They fight
> crime!
>
>

Damjan Jovanovic