On 11/21/2010 01:28 AM, Ryan Lortie wrote: > Hi Gary, > > On Sat, 2010-11-20 at 20:15 -0600, Gary Kramlich wrote: >> That leaves the data directory. However, the data directory on a unix >> machine ends up being ~/.local/share and putting a native plugin under a >> share directory seems to be completely wrong to me. > > Your concern here is misplaced. You can logically claim that it is > either completely incorrect to place native binaries in the user home > directory or that it is safe to blindly do so without consideration of > the "share" vs. "lib" issue. Which one you choose depends on your > assumption about the different sorts of computers that the user's home > directory might end up being used on.
If I didn't want to put native libraries in the user's home directory, then I wouldn't have run into this dilemma. You're right though, it is just a name, but that makes me wonder why there was a separation of cache, config, and data then... > Having a separate 'lib' directory doesn't automatically solve the > problem associated with trying to use a home directory that contains > binaries on multiple different architectures. It's just a name. I completely agree, but a plugin is not data, config, or cache, at least according to the definitions given in the specification. If the point of XDG_DATA_HOME is just for data that typically would go under a share directory (examples, pixmaps, etc) then why even have the share directory under .local? It seems to me that by adding another sub directory to ~/.local for data, that there was intent to expand on what could go in ~/.local in which case putting plugins and libraries in a lib sub directory makes total sense, at least to me. > Cheers -- Gary Kramlich <[email protected]>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
