Comment # 2
from Paul Howarth
(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: 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 > I could not find information about how to verify the signed file. > But after some searching this should give some hints: > > -%<- > $ gpg --verify SOURCES/elldata.tgz.asc SOURCES/elldata.tgz > # get key number > > gpg --recv-keys --keyserver hkp://pgp.mit.edu/ key B5444815 > gpg: "key" not a key ID: skipping > gpg: requesting key B5444815 from hkp server pgp.mit.edu > gpg: key B5444815: public key "Bill Allombert <ballombe@debian.org>" imported > gpg: no ultimately trusted keys found > gpg: Total number processed: 1 > gpg: imported: 1 > > $ gpg --verify SOURCES/elldata.tgz.asc SOURCES/elldata.tgz You can actually shorten this to: $ gpg --verify SOURCES/elldata.tgz.asc > 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)" > 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.
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