Spec URL: http://people.atrpms.net/~hdegoede/coda.spec SRPM URL: http://people.atrpms.net/~hdegoede/coda-6.9.3-1.fc10.src.rpm Description: Source package for the Coda file system. Three packages are provided by this rpm: the client and server and the backup components. Separately you must install a kernel module, or have a Coda enabled kernel, and you should get the Coda documentation package.
+ rpmlint output coda-client.x86_64: W: service-default-enabled /etc/rc.d/init.d/venus - This is the Coda cache manager, and I'm assuming that it doesn't listen on any network ports, so is safe to run by default. coda-client.x86_64: W: incoherent-init-script-name venus - rpmlint is complaining that the script is called 'venus' but the package is called 'coda-client'. There doesn't seem to be anything in the guidelines which mandates that they be given the same name. coda-vcodacon.x86_64: W: no-documentation + package name satisfies the packaging naming guidelines + specfile name matches the package base name + package should satisfy packaging guidelines + license meets guidelines and is acceptable to Fedora GPLv2 + license matches the actual package license + %doc includes license file + spec file written in American English + spec file is legible + upstream sources match sources in the srpm e80184573ed83cdf20d74a0e5861b24d + package successfully builds on at least one architecture x86-64 n/a ExcludeArch bugs filed + BuildRequires list all build dependencies Although I didn't get to verify this by building it in Koji. n/a %find_lang instead of %{_datadir}/locale/* n/a binary RPM with shared library files must call ldconfig in %post and %postun + does not use Prefix: /usr + package owns all directories it creates + no duplicate files in %files + %defattr line + %clean contains rm -rf $RPM_BUILD_ROOT + consistent use of macros + package must contain code or permissible content n/a large documentation files should go in -doc subpackage + files marked %doc should not affect package n/a header files should be in -devel n/a static libraries should be in -static n/a packages containing pkgconfig (.pc) files need 'Requires: pkgconfig' n/a libfoo.so must go in -devel n/a -devel must require the fully versioned base n/a packages should not contain libtool .la files n/a packages containing GUI apps must include %{name}.desktop file + packages must not own files or directories owned by other packages + %install must start with rm -rf %{buildroot} etc. + filenames must be valid UTF-8 Optional: n/a if there is no license file, packager should query upstream n/a translations of description and summary for non-English languages, if available - reviewer should build the package in mock - the package should build into binary RPMs on all supported architectures - review should test the package functions as described + scriptlets should be sane n/a pkgconfig files should go in -devel n/a shouldn't have file dependencies outside /etc /bin /sbin /usr/bin or /usr/sbin ============= This package looks fine. Obviously it depends on 3 other reviews being approved first before it can go into CVS. APPROVED.
Thanks for the review! New Package CVS Request ======================= Package Name: coda Short Description: Coda distributed file system Owners: jwrdegoede Branches: F-8 F-9 InitialCC: Cvsextras Commits: Yes p.s. Any chance you could take a look at the rpc2 review, plenty of comments but no reviewer sofar, should be even easier to review then this one :) , see bug 446652. Once that is approved the coda stack is complete.
cvs done.
Imported and build for rawhhide, I'll build and push this an update for F-8 / F-9 when rvm and rcp2 are tagged into the F-8 / F-9 buildroot.
I have been working on some (experimental, private) packages for coda and related libraries (since I work at CMU and share an office with the Coda lead programmer). They are accessible at /coda/coda.cs.cmu.edu/usr/agoode/devel/packaging or http://www.cs.cmu.edu/~agoode/coda-packaging/ Some recommendations (as found in my packages): * Splitting out /coda into another package. That way you avoid some disaster when trying to upgrade coda-client during mounted /coda. I call this package "coda-filesystem", which follows other Fedora conventions, but is a little odd sounding. * Use coda-client as the service name for the client, this is more intuitive and follows how the Debian packages are. * Split out gcodacon * Ship a venus.conf that sets the coda directories to places in /var/log, /var/run, etc Something needed but have not done yet: * Add /etc/udev/makedev.d/99-coda.nodes with contents "cfs0"
Also, in my packages, I made no attempt to get anything working but the client. Only coda-client is even tested with this specfile.
(In reply to comment #5) > I have been working on some (experimental, private) packages for coda and > related libraries (since I work at CMU and share an office with the Coda lead > programmer). > > They are accessible at > /coda/coda.cs.cmu.edu/usr/agoode/devel/packaging > or > http://www.cs.cmu.edu/~agoode/coda-packaging/ > Hi, Nice to meet you and thanks for the interest in my coda packages > Some recommendations (as found in my packages): > * Splitting out /coda into another package. That way you avoid some disaster > when trying to upgrade coda-client during mounted /coda. I call this package > "coda-filesystem", which follows other Fedora conventions, but is a little odd > sounding. > I've already solved this by creating /coda if it doesn't exit in %post, and owning it through %ghost. This IMHO is better, because even a coda-filesystem package might need an update one day, and then you still have a problem. > * Use coda-client as the service name for the client, this is more intuitive > and follows how the Debian packages are. > This deviates from upstream, and makes it harder to use things like the coda howto and other documents together with the packages. > * Split out gcodacon Why? > * Ship a venus.conf that sets the coda directories to places in /var/log, > /var/run, etc I've moved the entire venus cache, logs etc to /var/lib/coda by adding a /usr/coda symlink which points to /var/lib/coda > Something needed but have not done yet: > * Add /etc/udev/makedev.d/99-coda.nodes with contents "cfs0" This is not necessary the venus initscript loads the coda kernel module and then the nodes get created automatically by udev p.s. As you may have seen I've written new sysv style initscript scripts for these packages which fully follow the Fedora / RH initscript conventions. I would like to share these with upstream, what would be the best place to submit these?
(In reply to comment #7) > I've already solved this by creating /coda if it doesn't exit in %post, and > owning it through %ghost. This IMHO is better, because even a coda-filesystem > package might need an update one day, and then you still have a problem. Ok, that sounds good. > > > * Use coda-client as the service name for the client, this is more intuitive > > and follows how the Debian packages are. > > > > This deviates from upstream, and makes it harder to use things like the coda > howto and other documents together with the packages. This is true, but isn't /usr/coda really ugly? Also, when I say "Debian packages", I don't mean official packages (there aren't any), but the Debian packages that upstream makes for download. If you look at debian/ in the standard tarball, you will see the initscript and other files that use the FHS-style paths and the "coda-client" named service. More importantly, Coda predates Linux and the FHS. The config file allows for the customization of directories to fit a particular system. The defaults are generic, and not really correct for a modern Linux system. The defaults given in the debian directory should be closer to what a Linux system today should have. > > > * Split out gcodacon > > Why? > This is optional, but useful for avoiding dependences on Gtk. > > * Ship a venus.conf that sets the coda directories to places in /var/log, > > /var/run, etc > > I've moved the entire venus cache, logs etc to /var/lib/coda by adding a > /usr/coda symlink which points to /var/lib/coda > See above. I don't think /usr/coda should exist on Fedora. /coda is bad enough! (But unavoidable.) > > Something needed but have not done yet: > > * Add /etc/udev/makedev.d/99-coda.nodes with contents "cfs0" > > This is not necessary the venus initscript loads the coda kernel module and then > the nodes get created automatically by udev This is a race condition, yes? Or are you calling udev-settle? makedev.d avoids the race condition, and is what fuse does (which is similar to coda in some ways). > > p.s. > > As you may have seen I've written new sysv style initscript scripts for these > packages which fully follow the Fedora / RH initscript conventions. I would like > to share these with upstream, what would be the best place to submit these? > http://www.coda.cs.cmu.edu/trac Pull from git and file some tickets!
(In reply to comment #8) > (In reply to comment #7) > > > * Use coda-client as the service name for the client, this is more intuitive > > > and follows how the Debian packages are. > > > > > > > This deviates from upstream, and makes it harder to use things like the coda > > howto and other documents together with the packages. > > This is true, but isn't /usr/coda really ugly? Also, when I say "Debian > packages", I don't mean official packages (there aren't any), but the Debian > packages that upstream makes for download. If you look at debian/ in the > standard tarball, you will see the initscript and other files that use the > FHS-style paths and the "coda-client" named service. > > More importantly, Coda predates Linux and the FHS. The config file allows for > the customization of directories to fit a particular system. The defaults are > generic, and not really correct for a modern Linux system. The defaults given in > the debian directory should be closer to what a Linux system today should have. > Okay, I've taken a closer look at this and it seems that the coda-client indeed can be made fully FHS compliant by using venus.conf, I've just finished working on 6.9.3-2, which makes the necessary changes. > > > > > * Split out gcodacon > > > > Why? > > > > This is optional, but useful for avoiding dependences on Gtk. > rpm doesn't generate any gtk deps for gcodacon > > > * Ship a venus.conf that sets the coda directories to places in /var/log, > > > /var/run, etc > > > > I've moved the entire venus cache, logs etc to /var/lib/coda by adding a > > /usr/coda symlink which points to /var/lib/coda > > > > See above. I don't think /usr/coda should exist on Fedora. /coda is bad enough! > (But unavoidable.) > See above, fixed now. > > > Something needed but have not done yet: > > > * Add /etc/udev/makedev.d/99-coda.nodes with contents "cfs0" > > > > This is not necessary the venus initscript loads the coda kernel module and then > > the nodes get created automatically by udev > > This is a race condition, yes? Or are you calling udev-settle? makedev.d avoids > the race condition, and is what fuse does (which is similar to coda in some ways). > I'm calling udev-settle, as is the debian initscript and the initscript installed by make install. So summarizing, expect 6.9.3-2 soon in rawhide (and F-9 and F-8) with the client part now fully FHS compliant.
(In reply to comment #9) > > > > * Split out gcodacon > > > > > > Why? > > > > > > > This is optional, but useful for avoiding dependences on Gtk. > > > > rpm doesn't generate any gtk deps for gcodacon True, but it's wrong. :) Look at lines 16-19 of /usr/bin/gcodacon. > So summarizing, expect 6.9.3-2 soon in rawhide (and F-9 and F-8) with the client > part now fully FHS compliant. > Otherwise, looks good.