Re: plans for doom packages
On Fri, Jun 28, 2013 at 10:26:07AM -0300, gustavo panizzo <gfa> wrote:
> > that is exactly what i would like to change
> >
> > to
> >
> > /usr/share/applications/doom2-wad.desktop:
> > Exec=doom2
I see. For reference (particularly anyone following this not familiar with
Doom in particular), the original doom source code release from which all
doom engines (colloqually known as ports) derive was the unified source for
the games doom and doom2; it auto-detected which game it was running as
based on what IWAD it loaded (either by searching itself or via the -iwad
command line switch). I'm not sure but I don't believe it changed its
behaviour based on what the executable was named (e.g. presumed doom2 if
called doom2), and I don't believe any of the ports added that either.
> > being /usr/games/doom2 a wrapper generated by the engine and managed
> > through alternatives
Where should this wrapper live? In the *-wad packages generated by
game-data-packager? How would we handle when you have more than one such
package installed?
> my rationale behind this change is
> switches are broken btw different engines,
This is indeed true, although most engines don't break the key -iwad switch,
(chocolate-doom, prboom, prboom-plus, winmbf, zdoom, doom legacy, eternity,
zdaemon, boom, mbf don't). Of the two that do break it that I know of
(vavoom and deng), there's a workaround for vavoom in the current package.
What are the drawbacks of the workaround?
> and we can't expect to be fixed in the future
Really? Upstream are unlikely to accept patches?
> more engines could appear, more switches could be needed.
Yes they could, but why would adding switches necessarily break the semantics
of existing ones? They key switch we're concerned about is -iwad, really, from
the wrapper POV. I can't think of any else.
> wrappers are a solution for this
I'm still not sure what the problem is with things the way they are.
Reply to: