Spec URL: http://fedorapeople.org/~jlayton/fedfs-utils/fedfs-utils.spec SRPM URL: http://fedorapeople.org/~jlayton/fedfs-utils/fedfs-utils-0.7.0-1.fc15.src.rpm Description: RFC 5716 introduces the Federated File System (FedFS, for short). FedFS is an extensible standardized mechanism by which system administrators construct a coherent namespace across multiple file servers using file system referrals. A file system referral is like a symbolic link to another file system share, but it is not visible to applications. It behaves like an automounted directory where a new file system mount is done when an application first accesses that directory. The arguments of the mount operation are controlled by information returned by the file server. Today, file system referral mechanisms exist in several network file system protocols. FedFS provides its namespace features by leveraging referral mechanisms already built in to network file system protocols. Thus no change to file system protocols or clients is required. Currently, the Linux FedFS implementation supports only NFS version 4 referrals. More on NFS version 4 referrals can be found in RFC 3530. FedFS may support other network file system protocols in the future.
Also, note that I've started a feature page for fedfs that I'm targeting for F17: http://fedoraproject.org/wiki/Features/FedFS ...it's still skeletal at this point, but I'll flesh it out more in the near future.
(In reply to comment #1) > Also, note that I've started a feature page for fedfs that I'm targeting for > F17: > > http://fedoraproject.org/wiki/Features/FedFS > > ...it's still skeletal at this point, but I'll flesh it out more in the near > future. Just a couple of notes on the F17 project web site. 1. In the "Scope" section you might reference the fedfs-utils upstream project web site, for more information: http://oss.oracle.com/projects/fedfs-utils In addition to license information, interested readers can find presentation slides, the FedFS LDAP schema, and a project roadmap. 2. In the "Dependencies" section, you should list nfs-utils along with the kernel patches. Changes are needed to mountd in order to process junctions. I've discussed these plans with Steve, but we can fill in more details on this site if that's required. Additionally, LDAP servers need to have the FedFS LDAP schema installed. Finally, /etc/rpc needs to be updated to include the IANA-assigned fedfs RPC program number. There are bugzillas filed for each of these items. 3. We should note somewhere (maybe in the "Benefit to Fedora" section) that fedfs-utils is part of a larger, ongoing effort to build out storage administration features on Linux file servers. This includes, to name but a few: * The ability to manage NFS referrals either via FedFS or via a simple command line tool on file servers * Support for SMB2 in a FedFS framework * Support for NFSv4.1's fs_locations_info attribute * Client-side support for NFSv4 migration with transparent state migration * Support for transparent NFS client access to replicated file sets
Thanks Chuck. I've updated the wiki page with the above suggestions.
It's common to group the %files sections at the bottom and %package and %description sections at the top. defattr was found to be not necessary after EPEL 4. Add Changelog, COPYING and README to the base package via %doc. Use the name macro whereever it makes sense to replace the actual name, like in Source0. If you're not aiming for EPEL5 or older, Buildroot, clean section and the rm in the install section are not needed. Replace the .gz in the files sections with .* [makerpm@fedora15 fedfs-utils-0.7.0-1.fc15.src]$ rpmlint ../fedfs-utils-0.7.0-1.fc15.src ~/rpmbuild/RPMS/x86_64/fedfs-utils-* fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated fedfs-utils-client.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-client.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 141: warning: macro `NF' not defined fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 142: warning: macro `TA' not defined fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 144: warning: macro `FI' not defined fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 90: warning: macro `NF' not defined fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 91: warning: macro `TA' not defined fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 93: warning: macro `FI' not defined fedfs-utils-common.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-common.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated fedfs-utils-server.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-server.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated fedfs-utils-server.x86_64: W: non-standard-uid /var/lib/fedfs fedfs fedfs-utils-server.x86_64: W: non-standard-gid /var/lib/fedfs fedfs fedfs-utils-server.x86_64: E: non-standard-dir-perm /var/lib/fedfs 0700L fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction 6 packages and 1 specfiles checked; 1 errors, 19 warnings. You can try to iron out the glitches in the manpage after it's generated. I don't know, if it is possible to remove the cause. Use the _sharedstatedir macro for /var/lib. The sub-packages should require the common package, see: http://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package The common package can be labeled noarch. I don't know anything about fedfs-utils, but breaking a quarter of a megabyte into 5 parts is probably not necessary.
Proposed solutions: (In reply to comment #4) > > [makerpm@fedora15 fedfs-utils-0.7.0-1.fc15.src]$ rpmlint > ../fedfs-utils-0.7.0-1.fc15.src ~/rpmbuild/RPMS/x86_64/fedfs-utils-* > fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace -> > name space, name-space, names pace "name space" is fine, but "namespace" seems to be a common item of terminology. Should rpmlint be updated, or can we ignore this warning? > fedfs-utils-server.x86_64: W: non-standard-uid /var/lib/fedfs fedfs > fedfs-utils-server.x86_64: W: non-standard-gid /var/lib/fedfs fedfs I'd like a special user and group for fedfs operation, although we could also use the same one nfs-utils uses, which is "rpcuser" I believe. Really, though, this value needs to be specified via a ./configure option as well, to make it easy for distributions to set it how they like. I'm not familiar with the rules around UID and GID usage. > fedfs-utils-server.x86_64: E: non-standard-dir-perm /var/lib/fedfs 0700L What is suggested? > fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction resolve-junction is going away in 0.8.0, which is why I didn't compose a man page for it. However, we could easily add a stub man page in 0.7, similar to the man page for mount.nfs. > I don't know anything about fedfs-utils, but breaking a quarter of a megabyte > into 5 parts is probably not necessary. We could reduce it to just three: one common noarch package, one for client pieces, and one for everything else.
I've uploaded a newer fedfs-utils SRPM and specfile to my fedorapeople page: http://fedorapeople.org/~jlayton/fedfs-utils/0.7.0-2/ I think this addresses almost all of the things that rpmlint complained about. The only exceptions are: 1) the complaints about "namespace" and "automounted". I'd argue that those are valid terms and the dictionary just lacks them for whatever reason. I'd suggest that we just ignore those warnings. If that's not acceptable, then I suppose we could change them, but I'd rather not. 2) I did not change the layout/number of packages. We could reduce the number of packages if that's necessary, but this breaks things up in a reasonably granular way such that clients and admin machines won't need to have unnecessary binaries installed. I'm flexible on this point however if the reviewers think that this many packages is overkill. We could even reduce it to one single package -- after all, we ship nfs-utils as a single package... 3) I didn't worry about the resolve-junction manpage since that program is going away (as Chuck points out).
I've updated the package to 0.7.2 release and have added a systemd service file for rpc.fedfsd. http://fedorapeople.org/~jlayton/fedfs-utils/0.7.2-1/
Updated the package to 0.7.3 and respun the "contrib" patch to better match what will be in 0.8.0: http://fedorapeople.org/~jlayton/fedfs-utils/0.7.3-1/
For the record, the only rpmlint warnings left are these: fedfs-utils.src: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils.src: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated ...and I think those are just gaps in the dictionary. Also, I've left it as 5 packages for now. If it's really a problem to keep it that granular, then let me know.
MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review. $ rpmlint fedfs-utils*.rpm fedfs-utils.src: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils.src: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-client.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-client.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-common.noarch: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-common.noarch: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-server.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace fedfs-utils-server.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction 7 packages and 0 specfiles checked; 0 errors, 13 warnings. MUST: The package must be named according to the Package Naming Guidelines. OK MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. OK (fedfs-utils.spec) MUST: The package must meet the Packaging Guidelines. OK MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines. OK (License: GPLv2) MUST: The License field in the package spec file must match the actual license. OK (not v2+) MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc. OK (%doc COPYING README ChangeLog) MUST: The spec file must be written in American English. OK MUST: The spec file for the package MUST be legible. OK MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. wget http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-utils-0.7.3.tar.gz dad5ceedfb05974837673664de6b158a fedfs-utils-0.7.3.tar.gz dad5ceedfb05974837673664de6b158a fedfs-utils-0.7.3.tar.gz.1 OK MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. OK (http://koji.fedoraproject.org/koji/taskinfo?taskID=3554224) MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. OK (all primary architectures built) MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. OK (koji build was fine) MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. OK (no locales) MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. OK (no libraries) MUST: Packages must NOT bundle copies of system libraries. OK (no libraries) MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. OK MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. OK (/var/lib/fedfs created & owned) MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations) OK MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. OK MUST: Each package must consistently use macros. OK MUST: The package must contain code, or permissable content. OK MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). OK (no doc package, no large docs) MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. OK (%doc COPYING README ChangeLog) MUST: Header files must be in a -devel package. OK (no header files shipped) MUST: Static libraries must be in a -static package. OK (no libraries, static or otherwise) MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. OK (no libraries) MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release} OK (no devel pkg) MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. OK (none) MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. OK (no gui) MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. OK MUST: All filenames in rpm packages must be valid UTF-8. OK Looks fine to me. Thanks, -Eric
New Package SCM Request ======================= Package Name: fedfs-utils Short Description: Utilities for mounting and managing FedFS Owners: jlayton Branches: InitialCC:
Git done (by process-git-requests).
Thanks for all the help. I think we're done here!
Package Change Request ====================== Package Name: fedfs-utils New Branches: epel 6 Owners: ikent steved mrchuck We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6 systems. There is a dependency on the uriparser package, which exists in EPEL, but is not in the base EL6 packages.
(In reply to Chuck Lever from comment #14) > Package Change Request > ====================== > Package Name: fedfs-utils > New Branches: epel 6 > Owners: ikent steved mrchuck > > We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6 > systems. There is a dependency on the uriparser package, which exists in > EPEL, but is not in the base EL6 packages. Branch "epel 6" is invalid, oracle guy.
(In reply to Christopher Meng from comment #15) > (In reply to Chuck Lever from comment #14) > > Package Change Request > > ====================== > > Package Name: fedfs-utils > > New Branches: epel 6 > > Owners: ikent steved mrchuck > > > > We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6 > > systems. There is a dependency on the uriparser package, which exists in > > EPEL, but is not in the base EL6 packages. > > Branch "epel 6" is invalid, oracle guy. Help me out, then. What branch do I want?
Chuck, I think you want to follow the trail of breadcrumbs from here: http://fedoraproject.org/wiki/EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F Since this bug is closed, you'll either want to reopen it and take ownership of it or create a new bug.
(In reply to Jeff Layton from comment #17) > Chuck, I think you want to follow the trail of breadcrumbs from here: > > > http://fedoraproject.org/wiki/EPEL/ > FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F > > Since this bug is closed, you'll either want to reopen it and take ownership > of it or create a new bug. Hi Jeff- I'm looking at: http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL and https://fedoraproject.org/wiki/Package_SCM_admin_requests?rd=PackageMaintainers/CVSAdminProcedure Which seem to more or less agree with the link you posted: find the original package review bug (this one), leave it CLOSED, change the fedora-cvs field to "?", and post the request in that bug using the SCM Change Request Template. The only thing I missed was mentioning that I am one of the Fedora fedfs-utils package co-maintainers. I discussed this request at the June NFS Bake-a-thon with Steve Dickson (steved) in person, who is also interested in this change. I do not see mention in any of these links of which SCM branch to specify to request EPEL packaging. Maybe the right answer is "EL-6" ?
Yeah, I think it has to be 'el6', actually. IIRC, there's a script that scrapes these requests and does it automatically, so getting the form correct is important.
Package Change Request ====================== Package Name: fedfs-utils New Branches: el6 Owners: iankent steved mrchuck The fedfs-utils package maintainers would like to get fedfs-utils-0.9 into EPEL so that it can be installed on EL6 systems.