Re: Bug#821260: RFS: python-adventure/1.4-1 [ITP]
Bas Wijnen <firstname.lastname@example.org> writes:
> I didn't look at the package, but just a quick note:
Thanks. In the case of this package it is unusual; see its PyPI entry at
The game as I have packaged it is a normal command-line program: run the
command to play the game.
The Python module has additional behaviour though. It is able to play
the game by being imported in Python as a main module. That is, it
modifies the names available so that game commands can be typed as
I'm not completely decided on whether that is useful in Debian, nor
whether the module name ‘adventure’ is appropriate. But I would like to
leave the option open for some publicly-available import to provide that
feature in Python. That's why I have done the work to build the separate
‘python3-adventure’ binary package.
> Similarly for adventure-common: the usual reason for splitting off
> common files is that you don't want a copy for every arch on the
> mirrors […] Or do you have a different reason for the split?
Another common reason to build a ‘foo-common’ package is that there can
be multiple possible implementations of essentially the same ‘foo’
behaviour, that could each make use of common files. Adventure is one
such variously-implemented program.
> Do you expect any package (or user) to need the data files, but not
> the game?
I am making the ‘adventure-common’ package because it could be used by
other Adventure implementations.
\ “All opinions are not equal. Some are a very great deal more |
`\ robust, sophisticated, and well supported in logic and argument |
_o__) than others.” —Douglas Adams |
Ben Finney <email@example.com>