[Bug 218556] Review Request: ecryptfs-utils - Linux eCryptfs utilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: ecryptfs-utils - Linux eCryptfs utilities


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218556





------- Additional Comments From bjohnson@xxxxxxxxxxxx  2006-12-08 23:06 EST -------
rpmlint is much happier now.  Here is the output on the srpm and rpm:

W: ecryptfs-utils summary-not-capitalized eCryptfs mount helper and support
libraries
W: ecryptfs-utils devel-file-in-non-devel-package /usr/lib/libecryptfs.so

Package mock-builds for FC6.

As far as the first one, just to keep lint quit, maybe you'd change the summary
from "eCryptfs mount helper ..." to "The eCryptfs mount helper...".

As far as the second regarding libcryptfs.so, it should be removed from the
package if it is a development file and you don't intend to provide a -devel
package.  I see there are still .so files in /usr/lib/ecryptfs although you
never stated their purpose.  Are they dl'opened modules or develop libraries?

It's recommended that the Source directives are direct download links.  It's
also recommended that your first source sould be Source0:
Source0: http://downloads.sourceforge.net/ecryptfs/ecryptfs-utils-6.tar.bz2

Since its support in the kernel starts at a specific version number, the package
should require this number or greater.  This is a little more complicated that
it sounds, because although a kernel may have a number like 2.6.18, the kernel
developers might have (probably did) pulled in additional snapshot patches.  You
should check with the upstream RPM developers of the kernel or verify for
yourself what kernel number (exactly which RPM release) ecryptfs support starts in.

MUST Items:
- 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. The exception to this are directories listed explicitly
in the Filesystem Hierarchy Standard ([WWW]
http://www.pathname.com/fhs/pub/fhs-2.3.html), as it is safe to assume that
those directories exist.

Take ownership of %{_libdir}/ecryptfs via a %dir statement or by recommendation
below.

- 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.

See previous comments regarding .so files.



A couple of recommendations:

This is redundant, as make install will do it for you:
mkdir -p $RPM_BUILD_ROOT/sbin
mkdir -p $RPM_BUILD_ROOT/%{_libdir}/ecryptfs
mkdir -p $RPM_BUILD_ROOT/%{_bindir}
mkdir -p $RPM_BUILD_ROOT/%{_mandir}/man7

These lines:
%{_libdir}/ecryptfs/libecryptfs_pki_passphrase.so
%{_libdir}/ecryptfs/libecryptfs_pki_openssl.so
can be replaced with:
%{_libdir}/ecryptfs
which will include the files and directory and solve the directory ownership
problem above.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]