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

Bug#754441: RFS: gmastermind.app/0.6-1 [ITP] -- GNUstep based Mastermind (TM) clone



Riley Baird wrote:
> On 11/07/14 17:46, Yavor Doganov wrote:
> > The license is GPL-2+, AFAICS.
> 
> *Most* of GMastermind is released under GPL-2+. However, the README
> indicates that, as a whole, GMastermind is released under GPL-2 (so,
> it would apply to all files without a license header).

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).

> >  - Depends:
> >    Remove gnustep-gpbs.  The package is gone so your package will
> >    not be installable.  GNUstep Backend dependencies are volatile
> >    too, and are added automatically via libgnustep-gui's shlibs.
> >    No package should use them directly, that's asking for trouble
> >    and pain during GNUstep transitions.
> 
> Done. Was gnustep-gpbs replaced by another package and should I put
> that one as a dependency?

The gpbs daemon is in gnustep-back-common now.  You don't need to
depend on it, the dependency will be satisfied by gnustep-back0.24
which will be added via ${shlibs:Depends}.

> >  - 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.

> >  - You should move Resources to /usr/share/GNUstep and install a
> >    symlink, then the lintian override can be removed.
> >  - Move the /usr/bin symlink to /usr/games here.
> 
> 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

> > 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.

> > Take a look at (gs)dh_gnustep.  It is not very capable for apps,
> > unfortunately, but will add a gnustep-fhs-layout dependency via
> > ${gnustep:Depends}.
> 
> Do I need to do that for this package? I'll use it in future packages,
> but AFAIK, I think that I have met the FHS requirements for this package.

In short: no, you don't need to.

We are only doing this for the GNUstep LiveCD (a Debian derivative)
and for users that tend to install Debian GNUstep packages on systems
with gnustep-make configured with a different layout.  The package
will fail to install there because of this extra dependency (and
that's the intention).

All GNUstep packages in Debian must comply with the FHS.


Reply to: