I'm not a Debian developer, so take this all with a large grain of salt. On Sat, 2008-01-05 at 15:03 +0100, Jonas Eschenburg wrote: > 1. Some addons' shared libraries have dependencies to other addons. Do you have an example here? It seems like this is violating the addon abstraction, though I know nothing about this programming language. For example, I don't think I've ever seen a Perl or Python module that required a shared library from another module; they would just require the module itself and work with the Perl/Python API. If these addons are all built from the same source package, you're probably fine. If they don't, then I'm guessing you'll need to make that into a versioned shared library. > 2. Flux, an OpenGL-based GUI addon, contains a lot of image and font > resources. Those, of course, end up in /usr/lib and produce > lintian warnings such as "image-file-in-usr-lib". What am I > supposed to do about it? The design of putting code and data into > the same addon directory is not 'broken', it just differs from FHS > philosophy. If the images take up significant size, you should split them into an architecture independent package. You could install these into /usr/share and then either patch the addon to use them from there or make symlinks. > 3. The same addon contains .ttf files from various free fonts like > Vera. Those files are duplicates of the files in the corresponding > Debian packages, but they're renamed and put into a special folder > structure. Is it a) necessary to replace those files by symlinks > and b) can that be done automatically? If they're exact duplicates, I'd say you should use the existing packages. You could see about patching the addon to use .ttf files from the system location. This would be ideal, I think, as then it could use other installed fonts that the upstream addon package didn't ship, right? Richard
Attachment:
signature.asc
Description: This is a digitally signed message part