https://bugzilla.redhat.com/show_bug.cgi?id=1332607 Jerry James <loganjerry@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(loganjerry@gmail. | |com) | --- Comment #2 from Jerry James <loganjerry@xxxxxxxxx> --- (In reply to James Hogarth from comment #1) > * License field in spec > - The GPL file included only seems to specify GPL2 not GPL2+ > - Please fix this in the spec or clarify where the + comes from In doc/manual.xml, the <Copyright> section includes the "any later version" language. > - Incorrect fsf address found in license - please report upstream Will do. I notice that doc/manual.xml uses a modern style web address instead of a street address, so the old address in GPL is probably an oversight. > * Documentation in %{_gap_dir} which is /usr/lib/gap > - As per comments on bz1332605#c2 docs are here for runtime > documentation browser > - Accepted as per previous packages, perhaps draft gap guildelines to > FPC useful? Yes, I should definitely take that step. I have not done so yet because I've been kind of feeling my way into a set of best practices for GAP packages. I'm still not sure I've arrived there, but I've certainly built up a set of common practices that should be codified. I will take a stab at this and submit to FPC. > * The PackageInfo.g fiel (and upstream website) specifies GAPDoc as a > requirement > - GAPDoc-latex is a BR but no GAPDoc in requires? GAP itself won't even start unless GAPDoc is installed, so it is required by gap-core. On the other hand, the big pile of LaTeX packages required by GAPDoc-latex is not needed for normal day-to-day use of GAP, which is why they have been split out into the GAPDoc-latex subpackage. > * There are %config files in %{_gap_dir} > - Are these files marked as %config meant to be user editable? > - If they are can GAP packages be built with them in /etc ? > - If they need to be in /usr/lib/gap/%{pkgname} can that be a symlink to > etc? > - Seems to highlight the need for a GAP packaging draft guideline. Yes, they are meant to be user editable. They are read from init.g when the package is loaded. I'm not sure what the best option is here. Putting them into /etc implies that there is a single system-wide configuration that all users will want, which is not necessarily the case. Those files really ought to live under $HOME somewhere. So ... how about we put them in /etc, with either a patch to init.g to point to their new home or a symlink from /usr/lib/gap/%{pkgname}, and then have init.g also attempt to read files of the same names from, say, $HOME/.gap, with no error if those files don't exist? That will require a README to explain the situation to Fedora users. The idea is that users can override the system-wide settings that way. Honestly, I'm not sure that a system-wide setting even makes sense. Maybe we should dispense with the /etc versions, tell users that we're providing example config files, and they need to create the $HOME versions before this package will function at all. You know what? Debian has this packaged already. Just for laughs, I'm going to see what they did. > * Assuming functional based on %check passing > * Latest version is hard to check > - The upstream URL shows 2.1.2, the download on that page it 2.1.0 and > this is 2.1.4 > - How can we verify the latest version accurately? It appears that this author considers the GAP package repository at http://www.gap-system.org/Packages/packages.html to be the primary download site, and only updates the supposed package home page once in awhile. I will monitor that site for updates to this package. (This is the case with many of the GAP packages, by the way. The authors update their home pages only sporadically, but always upload the latest tarball to gap-system.org, because that is where GAP users look for new package versions.) Thank you for the review. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx