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

[bugzilla at redhat.com]

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


notting at redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |notting at redhat.com




------- Additional Comments From notting at redhat.com  2007-06-07 02:49 EST -------
MUST items:

 - Package meets naming and packaging guidelines - OK
 - Spec file matches base package name. - OK
 - Spec has consistant macro usage. - OK
 - Meets Packaging Guidelines. - OK
 - License  - OK
 - License field in spec matches - OK
 - License file included in package - OK
 - Spec in American English - OK
 - Spec is legible. - OK
 - Sources match upstream md5sum: - OK

 - Package needs ExcludeArch - OK
 - BuildRequires correct - OK
 - Spec handles locales/find_lang - N/A
 - Package is relocatable and has a reason to be. - N/A
 - Package has %defattr and permissions on files is good. - OK
 - Package has a correct %clean section. - OK
 - Package has correct buildroot - OK
      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 - Package is code or permissible content. - OK
 - Doc subpackage needed/used. - N/A
 - Packages %doc files don't affect runtime. - OK

 - Headers/static libs in -devel subpackage. - OK
 - Spec has needed ldconfig in post and postun - OK
 - .pc files in -devel subpackage/requires pkgconfig - N/A
 - .so files in -devel subpackage. - OK
 - -devel package Requires: %{name} = %{version}-%{release} - OK
 - .la files are removed.  - OK

 - Package is a GUI app and has a .desktop file - N/A

 - Package compiles and builds on at least one arch. - OK
 - Package has no duplicate files in %files. - OK
 - Package doesn't own any directories other packages own. - OK
 - Package owns all the directories it creates. - OK
 - No rpmlint output. ***

E: ecryptfs-utils binary-or-shlib-defines-rpath /sbin/mount.ecryptfs ['/usr/lib64']
E: ecryptfs-utils binary-or-shlib-defines-rpath /lib64/security/pam_ecryptfs.so
['/usr/lib64']
E: ecryptfs-utils binary-or-shlib-defines-rpath /usr/bin/ecryptfsd ['/usr/lib64']
E: ecryptfs-utils binary-or-shlib-defines-rpath /usr/bin/ecryptfs-manager
['/usr/lib64']

 - final provides and requires are sane: ***

Main package has:

Requires: keyutils openssl pam kernel >= 2.6.19

1) keyutils, openssl, pam requirements should be superfluous - library
dependencies take care of this
2) kernel requires are tricky. Generally, we do

Conflicts: kernel < 2.6.19

as there's no reason, for example, to pull a kernel into a buildroot.

SHOULD Items:

 - Should build in mock. - OK (tried x86_64)
 - Should build on all supported archs - build i386 non-mock
 - Should function as described. - mounted FS successfully
 - Should have sane scriptlets. - OK
 - Should have subpackages require base package with fully versioned depend. - OK
 - Should have dist tag - OK
 - Should package latest version - build checks were done with 16, even though
15 was here :)

MISC item:

So, general sanity checking:

/lib/security/pam_ecryptfs.so:
        linux-gate.so.1 =>  (0x00e9e000)
...        libdl.so.2 => /lib/libdl.so.2 (0x006a6000)
        libecryptfs.so.0 => /usr/lib/libecryptfs.so.0 (0x00b11000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x007c4000)
...
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x0056f000)


/sbin/mount.ecryptfs:
        linux-gate.so.1 =>  (0x00397000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x038a8000)
        libecryptfs.so.0 => /usr/lib/libecryptfs.so.0 (0x008eb000)
...
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x03e3a000)

That's bad; these shouldn't be linked against things in /usr/lib. (Yes, some
people still run /usr separate.) Moreover, I suspect that both of these will
also dlopen the plugins in $(libdir)/ecryptfs?

-devel: what, if anything, will ever build against this? If there's nothing, it
may not be worth shipping. (Also,does this package maintain a stable ABI?)



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