[Bug 210775] Review Request: Eternal Lands - a free MMORPG

[bugzilla at redhat.com]

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

Summary: Review Request: Eternal Lands - a free MMORPG


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





------- Additional Comments From meme at daughtersoftiresias.org  2006-10-14 19:58 EST -------
Now this is frustrating.  Because, according to this page: 
 
http://fedoraproject.org/wiki/Packaging/Guidelines 
 
"The goal of The Fedora Project is to work with the Linux community to build a 
complete, general purpose operating system exclusively from open source 
software. In accordance with that, all packages included in Fedora must be 
covered under an open source license.  
 
We clarify an open source license in three ways:  
 
* OSI-approved license. You can find the list of OSI approved licenses here:  
http://www.opensource.org/licenses/ " 
 
So, I went to http://www.opensource.org/licenses/, and I see this: 
 
http://www.opensource.org/licenses/qtpl.php 
 
What is up with this?  I just spent a couple hours packaging this because it 
looked like this license was acceptable.  Now you tell me that it isn't? 
 
Looking into it more, it seems you're talking about the restrictions to the 
license as opposed to the license itself.  For number 4, this RPM is a piece 
of client software.  Just because a server choses not to allow modified 
clients to connect doesn't mean that you can't modify the client.  You can 
modify this client to your heart's content -- you'll just need your own server 
if you want to connect legally. Any security changes that don't go straight 
into the EL tree or have EL permission should, responsibly, change the address 
that the server points to, just to make sure that users realize that it's a 
modified client.  If this is unacceptable to Fedora, then Fedora will *never* 
be able to have a MMORPG in with it, because modified clients are the bane of 
MMORPGs, as they allow botting.  EL is actually nicer than most -- you can use 
modified clients, so long as you register them and they're not obscenely 
cheating, and they're very good about accepting patches. 
 
As for #3, the first part is implicit in all licensing agreements.  You're 
never allowed to use other peoples' trademarks without their approval, whether 
their code is Open Source or not.  Is the second part a problem?  Right now, 
I'm looking at the LGPL, and it's little different: "You must cause the files 
modified to carry prominent notices stating that you changed the files and the 
date of any change." 
 
Oy.  Is there a way to get preapproval or anything so that this doesn't happen 
again in the future? 
 
Anyways, as to the other stuff: 
 
<I>1) Why do you use "-n eternallands-%{version}" parameter to %setup macro? 
By default, rpm tries to change directory to %{name}-%{version}.</I> 
 
I based this on the nethack-vultures specfile, which Ville built the framework 
of. 
 
<I>2) I think that inclusion wrapper as an another source would be better than 
creating it in spec file (only imho).</I> 
If you'll notice, part of the wrapper depends on the installation directory.  
Since it's so short, I figured this was cleaner than having a separate source 
that I'd have to sed to customize. 
 
<I>3) data files shouldn't go into %{_datadir}/games/%{name}, but 
%{_datadir}/%{name}. Read http://fedoraproject.org/wiki/Extras/SIGs/Games 
for further information.</I> 
 
Can do.  Once again, however, the nethack-vultures spec installed in there.  
So it must be wrong as well. 
 
<I>4) post scripts look wrongly (read http://fedoraproject.org/wiki/ 
PackagingDrafts/ScriptletSnippets)</I> 
 
This is also straight from nethack-vultures, and is code I was given from 
Ville.  What is the issue with what you see, out of curiosity -- is it the 
lack of an "if"? 
 
<I>And the last thing: creation of your own tarball may be a problem to a 
reviewer.  I think you should include all tarballs as sources and make any 
required modifictions in %prep section and/or patches.</I> 
 
But there are no tarballs except the initial and one update, which has been 
heavily modified over time by additional files (they're zips, not tarballs, 
but that's not important).  There are no up-to-date original tarballs, so 
there is no option but to create a new one each time.   
 

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.