Re: non-satisfyable Recommends: in main (was Re: Bug#661329: recommends doom-wad which is only provided by non-free doom-wad-shareware)
On Mon, Apr 30, 2012 at 10:24:17PM +0800, Thomas Goirand wrote:
> On 04/30/2012 05:33 PM, Jon Dowland wrote:
> > Oh joy-of-joys, a context free drive-by-CC to -devel, and a bug which indicates
> > an NMU without warning, DELAYED queue use or nmudiff, for a package to which
> > the maintainer is actively discussing the bug (not MIA), for a maintainer who
> > is just beginning their time with Debian and relies on support and sponsorship.
> > How inviting to the project!
> >
> > FWIW, I (or someone else) could quite easily contrive and upload a freedoom
> > derivative which worked with Doomsday and upload it. It would then satisfy this
> > technical requirement and thus the argument would go away. It would also be
> > a poor imitation of Freedoom (lack features), confusing to users and generally
> > be a complete waste of time
>
> Well, here's the maintainer's view on this:
>
> > The game should be able to run with free content as well, so I disagree
> > on that. Shall I just remove te requirement?
>
> I happen to agree with him, also because there's at least one GPL editor for
> doom, like doom builder:
> http://www.doombuilder.com/index.php?p=development
>
> "Doom Builder is an open source development released under GNU GPL.
> Everyone can learn from the source code and use it in a GPL compatible
> project."
>
> Yes, doom builder is a windows app, but there are many ways to run
> a windows APP (wine, ReactOS, etc.). [Before you ask: no, I didn't try
> to actually run doombuilder myself.]
There's also Yadex, which was (at one time) packaged in Debian, and WadC
(<http://jmtd.net/wadc/>), however…
> Or is it that doomsday still needs iwad files on top of the wad
> files for levels, sprites, and characters?
doomsday will need an internally-complete iwad: that is, one which provides
levels, sprites and sounds for the monsters in those levels, music to play
during the levels, textures for the walls and floors in those levels, and
sound effects for the environment and weapons exposed in those levels, and
possibly ones not exposed (the engine may perform availability checks to
determine the precise game it is supposed to be offering.)
The problem with Freedoom (which provides all of the above) is that the levels
in Freedoom make use of features introduced in a doom derivative called 'boom',
from which the vast majority of doom engines derive, but not all, including
doomsday. Doomsday will therefore crash trying to run those levels. (There
exists another port 'risen3d' which merged boom support into Doomsday -
<http://risen3d.drdteam.org/>, it is also, in theory, open source:
<http://risen3d.drdteam.org/source.htm>)
Note that chocolate-doom is another engine in the same situation (which is
in contrib). There have been noises that people might re-work Freedoom to
remove the Boom features, or make a Boom-free variant, but I haven't seen
anything beyond discussion.
Another interesting consideration: You could use doomsday and freedoom together
as long as you never played the freedoom levels. So, you could play a
third-party level. We could also package third-party levels. What would be
the situation then? All the required pieces to use the engine would be in main.
(I have thought that a bundle of some of the best F/OSS compatible Doom levels
would be worthwhile. Sadly most of the classic or historically noteable Doom
levels are not F/OSS compatible.)
> In any case, if you still think that this was a mistake that I did,
> I am sorry for it, but if that's the case, it's easy to fix:
> - reopen #661329
> - retitle it "doomsday should be in contrib, not in main" so that it's
> not miss-leading anymore.
Well the issue is not so much the decision but the actions. It would be nice
for you to submit the nmudiff, so Kees can merge it into his git repository.
AFAIK the next in-progress doomsday release was being prepared in a git
repository (which would add the VCS- headers, too)
Reply to: