Bug#691741: Provides: boom-engine, but does not supply /usr/games/boom

[Fabian Greffrath]

Am 08.11.2012 14:41, schrieb Fabian Greffrath:
> the string just as before. However, this may confuse users who want to
> pass the file name of an iwad in the current directory or in a
> directory relative to it. But changing this would break the current
> (though undocumented) behaviour, so I am not sure how to proceed.

I think the patch attached to this mail solves this issue way more 
elegantly. Whenever an iwad file is given on the command line, the 
path to that file is made the first choice in the list of possible 
iwaddirs. If it is an absolute path, the path itself is used for the 
iwaddir and separated from the file name. If it is a relative path or 
a single file name, the current directory is used for the iwaddir and 
the relative path or file name is used for the main wad file name.

That way, if you have a doom.wad in your current directory and type 
"vavoom -iwad doom.wad" it will take this file. If the file is absent, 
then it will take the one from the next directory in the iwaddirs 
array, i.e. typically /u/s/g/d/doom.wad. Thus, relative paths works as 
before, but precedence is taken by files that satisfy the path based 
on the current working directory. This is, IMHO, how all other tools 
in *NIX are expected to work. It is, furthermore, consistent with 
prboom's behaviour, at least in the limited range of tests that I 
performed.

I have, however, not yet figured out how the '-doom', '-doom2' etc. 
parameteres work in vavoom, but I think they are just shortcuts for 
the '-iwad' parameter in case there is more than one valid iwad file 
available in iwaddirs.

  - Fabian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vavoom-iwad.patch
Type: text/x-diff
Size: 461 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20121109/b340b95d/attachment.patch>