Comment # 3
from pcpa
(In reply to comment #2) > (In reply to comment #1) > > I would like to review this package. > > > > The first issues I noticed: > > > > data/elldata/README is not %doc tagged. > > Fixed in -2: Ok. > Spec URL: > http://subversion.city-fan.org/repos/cfo-repo/pari-elldata/branches/fedora/ > pari-elldata.spec > SRPM URL: > http://www.city-fan.org/~paul/extras/pari/pari-elldata-20120415-2.src.rpm > > README file also appears to be quite outdated, and only says the > > data is under the terms of the GNU GPL, no license version > > information. > > Not much we can do about outdated documentation unfortunately. I took the > license information from the upstream "packages" page: > > http://pari.math.u-bordeaux.fr/packages.html > > which says: > > "All packages are © the PARI group, distributed under the terms of the GNU > General Public License (GPL version 2 or any later version)" For elldata it should be clear the source is GPL and the author is very active in sagemath development at least, but the other pari- packages may need further investigation. For example, there is no license information about the original data at http://homepages.warwick.ac.uk/staff/J.E.Cremona/ftp/data/INDEX.html > > The README file also says it was last updated 11/04/2012, so, I > > think a better approach for version should be used. As > > Version: 20120415 > > has some flaws; personal experience with non versioned texlive > > packages... and suddenly a version being added to it, but those > > are rare cases, so, just a suggestion, e.g. either use > > <pari-version>.<date> or 0.<date>. > > Upstream lists the release date alongside each of the packages, so in the > absence of anything better I think it's reasonable to use that for a version > number. Clearly that will be a problem if a conventional versioning scheme > is introduced (though I think that's unlikely) but there's always the > possibility of an epoch bump to handle that eventuality. If you're dead > against that, another possibility would be to set the package version number > to zero and use the release date as the rpm release, which would handle an > upgrade to any sane versioning scheme by upstream without requiring an epoch > bump. No problems with it, was just asking for more clarification, and any change would just make the yyyymmdd format longer. Only issue I see now is that it should have a "Requires: pari-gp" for proper resolution of dependencies.
You are receiving this mail because:
- You are on the CC list for the bug.
_______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review