Spec URL: http://thias.fedorapeople.org/review/glusterfs/glusterfs.spec SRPM URL: http://thias.fedorapeople.org/review/glusterfs/glusterfs-1.3.7-4.src.rpm Description: GlusterFS is a clustered file-system capable of scaling to several peta-bytes. It aggregates various storage bricks over Infiniband RDMA or TCP/IP interconnect into one large parallel network file system. GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It borrows a powerful concept called Translators from GNU Hurd kernel. Much of the code in GlusterFS is in userspace and easily manageable.
SPECS differ: 4c4 < Release: 6%{?dist} --- > Release: 4%{?dist} 12d11 < Patch1: glusterfs-1.3.7-fstab-vol.patch 104d102 < %patch1 -p1 -b .fstab-vol 172d169 < %dir /var/log/glusterfs/ 193,196d189 < * Mon Dec 3 2007 Matthias Saou <http://freshrpms.net/> 1.3.7-6 < - Re-add the /var/log/glusterfs directory in the client sub-package (required). < - Include custom patch to support vol= in fstab for -n glusterfs client option. < Error building with new spec: glusterfs-1.3.7-fstab-vol.patch: No such file or directory
Yeah, the package has been updated a few times. Just look in the directory and you'll find the newer source rpms as well as that patch : http://thias.fedorapeople.org/review/glusterfs/
Ah, much better. This builds. rpmlint: Clean for SRPM. glusterfs-client.i386: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. glusterfs-client.i386: W: log-files-without-logrotate /var/log/glusterfs This package contains files in /var/log/ without adding logrotate configuration for them. glusterfs-devel.i386: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. glusterfs-devel.i386: W: no-dependency-on glusterfs glusterfs-libs.i386: W: obsolete-not-provided glusterfs-common If a package is obsoleted by a compatible replacement, the obsoleted package must also be provided in order to provide clean upgrade paths and not cause unnecessary dependency breakage. If the obsoleting package is not a compatible replacement for the old one, leave out the provides. glusterfs-server.i386: W: log-files-without-logrotate /var/log/glusterfs This package contains files in /var/log/ without adding logrotate configuration for them. glusterfs-server.i386: W: incoherent-subsys /etc/init.d/glusterfsd $prog The filename of your lock file in /var/lock/subsys/ is incoherent with your actual init script name. For example, if your script name is httpd, you have to use 'httpd' as the filename in your subsys directory. It is also possible that rpmlint gets this wrong, especially if the init script contains nontrivial shell variables and/or assignments. These cases usually manifest themselves when rpmlint reports that the subsys name starts a with '$'; in these cases a warning instead of an error is reported and you should check the script manually. glusterfs-server.i386: W: incoherent-subsys /etc/init.d/glusterfsd $prog The filename of your lock file in /var/lock/subsys/ is incoherent with your actual init script name. For example, if your script name is httpd, you have to use 'httpd' as the filename in your subsys directory. It is also possible that rpmlint gets this wrong, especially if the init script contains nontrivial shell variables and/or assignments. These cases usually manifest themselves when rpmlint reports that the subsys name starts a with '$'; in these cases a warning instead of an error is reported and you should check the script manually. glusterfs-server.i386: W: incoherent-subsys /etc/init.d/glusterfsd $prog The filename of your lock file in /var/lock/subsys/ is incoherent with your actual init script name. For example, if your script name is httpd, you have to use 'httpd' as the filename in your subsys directory. It is also possible that rpmlint gets this wrong, especially if the init script contains nontrivial shell variables and/or assignments. These cases usually manifest themselves when rpmlint reports that the subsys name starts a with '$'; in these cases a warning instead of an error is reported and you should check the script manually. glusterfs-server.i386: W: incoherent-init-script-name glusterfsd The init script name should be the same as the package name in lower case, or one with 'd' appended if it invokes a process by that name.
Hmm, I'm not sure what copy/pasting rpmlint messages brings us... - Docs : they're in the libs package which is required by both the client and server packages in order to not duplicate them. - Log rotation : the server doesn't support log rotation, so it's not possible to include a logrotate entry for now, and I think it's the same for the client (feel free to check) - Devel doesn't require the "main" package, because there is no such package... it does properly require the libs sub-package. - Obsoletes isn't provided because nothing is known to require the old name. - Incoherent subsys and init script name are false positives. I'm glad someone takes the time to look at the package, but I'd appreciate even more if it wasn't just to report superficial rpmlint warnings. If you could manually write what you think is wrong and needs fixing, I would really appreciate.
My point in including the rpmlint output was simply to fulfill the first MUST in the ReviewGuidelines, which I belive to be valuable. As long as there's a rational reason for ignoring an rpmlint warning, I'm OK with doing it, as long as it's documented in the review bug, and it is, so that's fine with me. More very shortly. . .
Everything else looks great upon full review. APPROVED.
FYI, the next release will implement log rotation upon SIGHUP, so I'll add that to the package when I'll update it. I'll also try to include better docs, but it isn't that easy, since upstream relies heavily upon their wiki. Thanks for the review! New Package CVS Request ======================= Package Name: glusterfs Short Description: Cluster File System Owners: thias Branches: F-7 F-8 EL-4 EL-5 InitialCC: Cvsextras Commits: yes
> FYI, the next release will implement log rotation upon SIGHUP, so I'll add that > to the package when I'll update it. I'll also try to include better docs, but it > isn't that easy, since upstream relies heavily upon their wiki. I can see where that would complicate things. :) > Thanks for the review! Very welcome.
Are the EL branches useful here? RHEL doesn't ship with FUSE at all, so can this package even build there?
(In reply to comment #9) > Are the EL branches useful here? RHEL doesn't ship with FUSE at all, so can this > package even build there? Oops, very good remark indeed. But the server side might be useful on RHEL, as it doesn't require fuse. The best solution would probably be to build the RHEL packages with the client sub-package disabled by default, and include a rebuild option to enable it (for people who, like me, have their own RHEL fuse kernel module package). Does it sound like a plan?
Sounds reasonable to me.
oh, I missed that the server package doesn't need fuse. Yeah, that sounds very reasonable, just wanted to make sure the EL branches would be useful. cvs done.
A. Very useful,. using it myself now from my review builds. B. Any plans to build it in Fedora? :)
I've rebuilt glusterfs on all requested branches. The tricky ones were : * Both EL, for which I added the "--without client" rebuild option. * EL-4 in which python is too old, so I added the "--without python" option. Maybe I'll poke upstream about the fact that it would have been much easier for me if the features just got disabled if the requirements aren't met, as it's currently required to explicitly pass configure options to disable the features when such is the case.
Package Change Request ====================== Package Name: glusterfs New Branches: Owners: kkeithle InitialCC: matthias,jonathansteffan Change owner to kkeithle. Matthias Saou (thias) has released ownership to allow me to take over ownership. http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages says ownership changes can me made through the package database web interface, but where? Or by opening an Admin request, but how?
Use pkgdb.