Bug 446653 - Review Request: coda - Coda distributed file system
Review Request: coda - Coda distributed file system
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Richard W.M. Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-15 11:09 EDT by Hans de Goede
Modified: 2008-05-20 21:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-17 01:44:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rjones: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2008-05-15 11:09:53 EDT
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.
Comment 1 Richard W.M. Jones 2008-05-16 04:42:14 EDT
+ 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.
Comment 2 Hans de Goede 2008-05-16 08:37:35 EDT
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.

Comment 3 Kevin Fenzi 2008-05-16 11:50:42 EDT
cvs done.
Comment 4 Hans de Goede 2008-05-17 01:44:14 EDT
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.
Comment 5 Adam Goode 2008-05-17 20:48:31 EDT
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"
Comment 6 Adam Goode 2008-05-17 21:00:55 EDT
Also, in my packages, I made no attempt to get anything working but the client.
Only coda-client is even tested with this specfile.
Comment 7 Hans de Goede 2008-05-18 03:35:04 EDT
(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?
Comment 8 Adam Goode 2008-05-19 10:34:56 EDT
(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!
Comment 9 Hans de Goede 2008-05-20 14:26:34 EDT
(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.
Comment 10 Adam Goode 2008-05-20 21:59:10 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.