[Bug 509160] Review Request: mine_detector – a mine-finding game

bugzilla at redhat.com bugzilla at redhat.com
Mon Jan 25 22:51:04 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=509160

--- Comment #9 from David A. Wheeler <dwheeler at dwheeler.com> 2010-01-25 17:51:00 EST ---
First, here are some initial impressions after reading the spec file and
looking over the code.

First, regarding the package name.  Fedora naming conventions are here:
http://fedoraproject.org/wiki/Packaging:NamingGuidelines
Comment 1 correctly notes that there are issues with using an underscore in
package names.  On the other hand, comment 2 has a reasonable rationale for the
name the way it is.
I re-read the naming guidelines, which specifically say:
"When naming a package, the name should match the upstream tarball or project
name from which this software came....
it is possible that the upstream name does not fall into the Common Character
Set . If this is the case, refer to: When Upstream Naming is outside of the
specified character set...
The maintainer must NOT use an underscore '_', a plus '+', or a period '.' as a
delimiter... packages where the upstream name naturally contains an underscore
are excluded from this."

Some may disagree with me, but I think this use of "_" is acceptable, because
it is part of the upstream name, just like it is in "tcp_wrappers".

It's weird that it doesn't touch %{SOURCE3} during %prep or %build. it only
shows up in %install.   I would expect that to be copied into the build areas
during %prep, then copy it out during %install.  By the time you hit %install I
expect that only the files in the build would be read from, and that writes
would generally only write to (install to) the buildroot.  That could be a real
issue if rpmbuild were modified in the future to enforce that... could you
change it?

There are no official Ada-specific guidelines for Fedora, so I obviously can't
refer to them.  I did peek at the Debian Ada policy, which isn't formally
required by Fedora but I thought might be helpful:
http://people.debian.org/~lbrenta/debian-ada-policy.html
However, the technical guidelines from that document focuses on creating
libraries, which isn't relevant here.

Although there's no separate licensing file, it's REALLY obvious that it's
GPL'ed once you look at the code.  *EVERY* .ads (spec) and .adb (body) created
by a human (ignoring b~mine_detector* which is auto-generated) has this
boilerplate:
-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; version 2.
The project file "mine_detector.gpr" says:
-- This is free software; you can redistribute it and/or modify it under
-- terms of the GNU General Public License as published by the Free Software
-- Foundation; either version 2, or (at your option) any later version.
However, "mine_detector.gpr" is not from the distributed tarball (and doesn't
have code anyway), so I think it'd be safer to simply label the license as
"GPLv2", since that's what the code files say.
So I guess I'll retract my comment in comment 8.  In this case, the licensing
is NOT unclear, it's just that the license file isn't there as a separate file.
In this case, Fedora applicable policy is that "If the source package does not
include the text of the license(s), the packager should contact upstream and
encourage them to correct this mistake."

Have you encouraged them to correct this mistake, and re-release a version with
an included license file?  You don't have to wait til they do so, just simply
make the request.

I'm glad to see that there's a .desktop file.  Great!

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list