* Jonas Eschenburg <[EMAIL PROTECTED]> [080105 15:03]:
> 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.
As is left-hand traffic in right-hand traffic countries or vice versa.
There are many different approaches to deal with this:
- for a small amount of files I'd say it is normaly safe to ignore it
(though that does not seem to be the case here)
- put parts with architecture-independent data to /usr/share and
symlink them. That is what usually takes the last efford and when
directories are at least locally consistent (like images in a
images subdir) can be relatively good. Having to sort things on
a per-file basis can be ugly, though...
Depending on the data, also the other way around is possible, i.e.
having everything in /usr/share and only sorting the architecture
dependent data out and putting that in /usr/lib.
- patch the program to look in multiple places. How easy or difficult
this is depends on how it is implemented. If every file is looked
for in a search path, the search path could simply also contain
the /usr/share directory. When things are searched relatively
to other stuff (like a image in the same directory as a library,
or first searching the plugin dir and than looking for stuff in
there), things get more complicated, but sometime can still be
relatively easy. (If you know that only shared libraries are
architecture dependent and everything else is not, for example,
an (slighly ugly, but very effective) way might be to just
try again a dl_open again with lib replaces by share if the first
fails).
> 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?
I don't know what is necessary here, but I'd strongly recommend to find
a way to use the normal fonts. Also fonts that are not yet in Debian
might be able to be included in Debian as seperate packages, so also
other software can benefit from it. (And when it cannot, it most likely
might be problematic in this package. Font licenses tend to be seldom
looked at and often very strange). I think in this case it would be
really be best if there was a way to have the global fonts used without
having to create symlinks, as I guess symlinks might easily break in
the long run.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
