Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone
> I don't think that this was the author's intention. There are plenty
> of Info.plist files where GPL 2.0 is stated, but it doesn't mean "GPL
> 2.0 only". To be sure, you could clarify with upstream (write to
> gap-dev-discuss@nongnu.org rather than via Savannah's interface).
>From a legal point of view, GPL 2.0 does mean GPL 2.0 only, but I agree
that this probably wasn't the author's intention. To be sure of this,
though, I'd have to get confirmation from all of the contributors;
writing to upstream wouldn't be enough. Should I try to do this?
>>> - You use $(optim) but the conditional to define the variable is
>>> missing.
>>
>> Removed
>
> You'd better add the conditional so that the package can be easily
> rebuilt for debugging without source modifications (debug=yes defines
> some debugging macros, it's not only the optimization level). We
> should probably add this snippet to config.mk instead of duplicating
> it everywhere.
Done
> Hmm. This line is redundant:
>
> dh_link usr/games/GMastermind usr/games/gmastermind.app
>
> And more importantly, you are not creating the symlink from /usr/share
> to /usr/lib so the app won't be able to find its own resource bundle.
> Also, you must move Resources to a directory named after the app so
> that it is clear that it belongs to this package.
> Something like this (untested):
>
> override_dh_link:
> mv $(d_app)/usr/bin/GMastermind $(d_app)/usr/games
> rm -rf $(d_app)/usr/bin
> mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/*.app/Resources \
> $(d_app)/usr/share/GNUstep/GMastermind.app
> dh_link /usr/share/GNUstep/GMastermind.app \
> $(GNUSTEP_SYSTEM_APPS)/GMastermind.app/Resources
Done. (I've added some mkdir -p lines in there so that it compiles.)
>>> gmastermind.app.6:
>>> Likewise. The manpage should be named after the binary, and you
>>> already have GMastermind.6.
>>
>> Are you sure? People that have typed `apt-get install gmastermind.app'
>> will most likely try `man gmastermind.app' next.
>
> Yes, I am sure. There is no guarantee that a binary package should
> contain a program of the same name, and never was. The user is armed
> with "dpkg -L" and can figure out what to start, configure, or read
> after installation.
Removed
I've just put the new package is on mentors
Reply to: