[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

doom packaging transition: removing doom2.wad alternatives



Hello,

At present, freedoom installs an alternative into
/usr/share/games/doom/doom2.wad. Doom engines search in
/usr/share/games/doom for data when they are invoked, so
this allows prboom to find freedoom (or whatever else is
providing that alternative -- e.g. official game data via
game-data-packager).

freedoom actually uses some features not found in the
original doom from the "boom" engine (which prboom
supports). However I have just uploaded chocolate-doom
(c-d) which does not support these features. Thus if
freedoom provides doom2.wad, c-d will crash on startup in
some circumstances. I therefore made c-d conflict with
freedoom for now.

The solution is quite simple. prboom upstream now support
looking for freedoom.wad as well as the official names
(patch from Fedora who did that rather than juggle
alternatives like ourselves). We make freedoom install
directly to /usr/share/games/doom/freedoom.wad and do away
with the alternative altogether. This way
prboom,freedoom,chocolate-doom and official game data can
all co-exist peacefully.

I updated the doom-guidelines in SVN with the changes
yesterday and the adjusted freedoom in a branch
"no_iwad_alternatives".  After a bit more testing (and c-d
escaping NEW) I will make that upload then new
game-data-packager and chocolate-doom uploads (prboom will
not need to be changed). The freedoom package becomes a lot
simpler with no prerm scripts, a stripped down postinst and
no lintian overrides.


-- 
Jon Dowland
http://jmtd.net/

Attachment: signature.asc
Description: Digital signature


Reply to: