Bug 223627
Summary: | Review Request: system-switch-java - Java toolset switcher | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thomas Fitzsimmons <fitzsim> |
Component: | Package Review | Assignee: | Andrew Overholt <overholt> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | anze.zagar, overholt |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-01-24 22:23:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779, 195649 |
Description
Thomas Fitzsimmons
2007-01-20 22:54:45 UTC
I'll take this one. Review: MUST: ? is this appropriate for Fedora? I guess with the pending release of OpenJDK it's fine. I'm just wondering whether people will be concerned that we're "making it too easy for people to use non-free software". I guess it's not really helping them to install it, but just to use it once they've got it installed, kinda like ex. rhythmbox working with the gstreamer MP3 plugin. * rpmlint on system-switch-java srpm gives no output ? package is named appropriately should the gui subpackage be 'gtk' instead of 'gnome'? are you calling it the "Duke Toolset Switcher" to get around the legal issues surrounding use of "Java"? * specfile name matches %{name} * package meets packaging guidelines. * license field matches the actual license. * license is open source-compatible. * license text included in package and marked with %doc * specfile written in American English X specfile is legible your changelog entry has a weird date format and it seems too early :) X source files match upstream can you host the tarball somewhere? can we do an md5sum somehow? * package successfully compiles and builds on at least x86 X BuildRequires are proper see below about desktop-file-utils * find_lang usage correct * package is not relocatable X package owns all directories and files is the ownership of %{_datadir}/pixmaps/*, etc. correct? X no %files duplicates why are the %doc files listed twice * file permissions are fine; %defattrs present * %clean present * macro usage is consistent * package contains code * no large docs so no -doc subpackage * %doc files don't affect runtime (N/A) * no shared libraries are present * no pkgconfig or header files * no -devel package * no .la files X desktop file you need to run desktop-file-install in %install and BuildRequires: desktop-file-utils * not a web app. * file ownership fine * binary RPMs function on x86 (well, I don't have any other JVMs to test against by both the GUI and the TUI seem to interact properly with consolehelper/pam and don't crash) * final provides and requires are sane $ rpm -q --provides -p system-switch-java-1.0.0-1.noarch.rpm config(system-switch-java) = 1.0.0-1 system-switch-java = 1.0.0-1 $ rpm -q --provides -p system-switch-java-gnome-1.0.0-1.noarch.rpm system-switch-java-gnome = 1.0.0-1 $ rpm -q --requires -p system-switch-java-1.0.0-1.noarch.rpm /usr/bin/env chkconfig config(system-switch-java) = 1.0.0-1 libuser newt python rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 usermode $ rpm -q --requires -p system-switch-java-gnome-1.0.0-1.noarch.rpm libglade2 pygtk2 pygtk2-libglade rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 system-switch-java = 1.0.0-1 usermode-gtk SHOULD: * package includes license text * package builds on i386 * package builds in mock X consider using make %{?_smp_mflags} (In reply to comment #2) > Review: > > MUST: > ? is this appropriate for Fedora? I guess with the pending release of > OpenJDK it's fine. I'm just wondering whether people will be > concerned that we're "making it too easy for people to use non-free > software". I guess it's not really helping them to install it, but > just to use it once they've got it installed, kinda like ex. rhythmbox > working with the gstreamer MP3 plugin. Yes, I'm readying Fedora Extras for smooth integration of OpenJDK alongside java-gcj-compat. > * rpmlint on system-switch-java srpm gives no output > ? package is named appropriately > should the gui subpackage be 'gtk' instead of 'gnome'? I renamed it 'system-switch-java-gui'. > are you calling it the "Duke Toolset Switcher" to get around the legal issues > surrounding use of "Java"? Yes, I didn't want to misrepresent the switcher as a Java-trademarked tool. But when re-examining this, I realized that System->Administration entries should be simple, descriptive names rather than tool titles anyway. So I've settled on just "Java Toolset" for the menu entry, and "Java Toolset Configuration" for the window title. This implies "configuring the Java or Java-like toolset" rather than "running the Java(TM) Toolset Switcher". > * specfile name matches %{name} > * package meets packaging guidelines. > * license field matches the actual license. > * license is open source-compatible. > * license text included in package and marked with %doc > * specfile written in American English > X specfile is legible > your changelog entry has a weird date format and it seems too early :) The date format is standard, but I updated the entry to be more current. > X source files match upstream > can you host the tarball somewhere? I'd like to maintain this as an SRPM-only package for now. > can we do an md5sum somehow? 9403b60da2e2bd3117f170d75a507ad3 SOURCES/system-switch-java-1.0.0.tar.bz2 > * package successfully compiles and builds on at least x86 > X BuildRequires are proper > see below about desktop-file-utils Fixed. > * find_lang usage correct > * package is not relocatable > X package owns all directories and files > is the ownership of %{_datadir}/pixmaps/*, etc. correct? It turns out I didn't need the application-specific pixmaps sub-directory. Fixed. > X no %files duplicates > why are the %doc files listed twice Fixed. > * file permissions are fine; %defattrs present > * %clean present > * macro usage is consistent > * package contains code > * no large docs so no -doc subpackage > * %doc files don't affect runtime (N/A) > * no shared libraries are present > * no pkgconfig or header files > * no -devel package > * no .la files > X desktop file > you need to run desktop-file-install in %install and BuildRequires: > desktop-file-utils Fixed. > * not a web app. > * file ownership fine > * binary RPMs function on x86 (well, I don't have any other JVMs to test > against by both the GUI and the TUI seem to interact properly with > consolehelper/pam and don't crash) > * final provides and requires are sane > > $ rpm -q --provides -p system-switch-java-1.0.0-1.noarch.rpm > config(system-switch-java) = 1.0.0-1 > system-switch-java = 1.0.0-1 > > $ rpm -q --provides -p system-switch-java-gnome-1.0.0-1.noarch.rpm > system-switch-java-gnome = 1.0.0-1 > > $ rpm -q --requires -p system-switch-java-1.0.0-1.noarch.rpm > /usr/bin/env > chkconfig > config(system-switch-java) = 1.0.0-1 > libuser > newt > python > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > usermode > > $ rpm -q --requires -p system-switch-java-gnome-1.0.0-1.noarch.rpm > libglade2 > pygtk2 > pygtk2-libglade > rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > system-switch-java = 1.0.0-1 > usermode-gtk > > SHOULD: > * package includes license text > * package builds on i386 > * package builds in mock > X consider using make %{?_smp_mflags} Fixed. I uploaded the updated spec and SRPM files. The URLs are the same as above. (In reply to comment #3) > (In reply to comment #2) > > can we do an md5sum somehow? > > 9403b60da2e2bd3117f170d75a507ad3 SOURCES/system-switch-java-1.0.0.tar.bz2 Okay, I've verified that I've got the same one. My only remaining questions surround the use of consolehelper and pam. But I assume you know what you're doing here :) Thus ... APPROVED. Thanks, Tom. I do not want to sound picky, but - the URL included in the spec is not very useful. - The purpose of the md5sum check is to guarantee that the file included in the src.rpm coincides with the one from the upstream source. Computing the md5sum by the packager and by the reviewer based on the SAME file extracted from the same src.rpm guarantees nothing. - each modification to the spec should be reflected in the release tag and in the changelog In this special case, I suggest including a comment in the spec, specifying that there is no other upstream but the src.rpm and, also, defining a real path for the said src.rpm (hosting it for instance on http://fitzsim.org or on people.redhat.com) (In reply to comment #5) > I do not want to sound picky, I don't think any of it sounds picky :) The only thing I disagree with is this: > - each modification to the spec should be reflected in the release tag and in > the changelog Does it really matter if the release tag is bumped for pre-first build fixes? I know 'the more the merrier', but as this package is a frontend to alternatives (specific to java); I want to draw your attention to another pygtk frontend call galternatives (already in Extras). It works for all packages using /usr/sbin/alternatives and its more fine-grained. When i tried this package, it only shows one radio button with 'GCJ' selected, so I figure it does all the other work in the background given multiple java implementations. However, with galternatives, there are many pieces (related to java) that can be selected alternatively, 'java', 'javac' 'jre_1.4.2', etc. (In reply to comment #6) As far as I know, yes, as subsequent versions can be used to follow the track and examine what modifications have been performed. See also http://fedoraproject.org/wiki/Packaging/NamingGuidelines?highlight=%28release%29%7C%28bump%29#head-5ea39bbc33cf351b41b51325ac3527eff4c58dac I bet this requirement is in the wiki, too... but I can't locate it now :) (In reply to comment #5) > I do not want to sound picky, but > - the URL included in the spec is not very useful. I'll change it to: http://download.fedora.redhat.com/pub/fedora/linux/extras/7/SRPMS/system-switch-java-%{version}-%{release}.src.rpm once the '7' directory has been created. > - The purpose of the md5sum check is to guarantee that the file included in the > src.rpm coincides with the one from the upstream source. Computing the md5sum by > the packager and by the reviewer based on the SAME file extracted from the same > src.rpm guarantees nothing. It guarantees that the reviewer is reviewing the same tarball that I think he's reviewing (i.e., that I didn't build the wrong tarball into the to-be-reviewed src.rpm). But I agree that in the case of no-upstream packages like this, the md5sum step of the review process is less meaningful. > - each modification to the spec should be reflected in the release tag and in > the changelog Not for review packages that have not yet entered the revision control system. > > In this special case, I suggest including a comment in the spec, specifying that > there is no other upstream but the src.rpm OK, will do. > and, also, defining a real path for > the said src.rpm (hosting it for instance on http://fitzsim.org or on > people.redhat.com) I'm not going to do that because I don't intend to keep the fitzsim.org src.rpm up-to-date. (In reply to comment #7) > I know 'the more the merrier', but as this package is a frontend to alternatives > (specific to java); I want to draw your attention to another pygtk frontend call > galternatives (already in Extras). It works for all packages using > /usr/sbin/alternatives and its more fine-grained. When i tried this package, it > only shows one radio button with 'GCJ' selected, so I figure it does all the > other work in the background given multiple java implementations. However, with > galternatives, there are many pieces (related to java) that can be selected > alternatively, 'java', 'javac' 'jre_1.4.2', etc. Yes, system-switch-java is intended to allow an administrator to easily select the default Java toolset, which includes all relevant alternatives for the selected Java vendor/version combination. I'll recommend that administrators wanting finer-grained control over these alternatives should use galternatives. the url is supposed to point at the upstream project. if there is not one then you need to create one. (In reply to comment #11) > the url is supposed to point at the upstream project. if there is not one > then you need to create one. I think this package is specific enough to Fedora that it doesn't warrant a separate upstream project. But since two people have mentioned this, what I'll do is upload the release tarballs someplace convenient, like: ftp://sources.redhat.com/pub/rhug/ Package built in devel. Closing. I created a very similar tool that I've been successfully using for about a year now but only recently found time to put it on sourceforge. Just thought you might want to check out that tool as well: http://sourceforge.net/projects/javaselector There's also a spec file, source rpm and binary rpm for FC2, 4 & 6. |