Bug 249815

Summary: move libgcrypt shared library from /usr/lib to /lib
Product: [Fedora] Fedora Reporter: Till Maas <opensource>
Component: libgcryptAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: rawhideCC: agk, dwysocha, matthias, mbroz, opensource, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.2.4-2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-07-27 14:28:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 243228    

Description Till Maas 2007-07-27 09:21:28 UTC 
+++ This bug was initially created as a clone of Bug #243228 +++

This will break things using /etc/crypttab and a separate /usr

-- Additional comment from opensource on 2007-07-26 13:46 EST --
Cryptsetup-luks in Fedora 7 and before were build statically, this changed with
1.0.3-5 in rawhide. I do not know why this changed, but I guess we should either
put the following libraries into /lib
        libpopt.so.0 => /usr/lib/libpopt.so.0 (0x0012e000)
        libcryptsetup.so.0 => /usr/lib/libcryptsetup.so.0 (0x00136000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0x001b5000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x47d8f000)
or go back to building it statically.

This not only breaks existing installations, but also blocks Bug #124789
(encrypted root support).

There was also a bug report for cryptsetup to build it statically: #129926,
which was closed a long time ago.




-- Additional comment from opensource on 2007-07-26 18:55 EST --
I commited the necessary changes to cvs to build it statically again, there is a
scratch build available:
http://koji.fedoraproject.org/koji/taskinfo?taskID=78776

-- Additional comment from katzj on 2007-07-26 19:42 EST --
Static linking isn't the right answer, though, and is explicitly disallowed per
the packaging guidelines.  The fact that it's needed in early boot isn't a
reason to link it statically; instead, it's a reason to get libraries moved to /lib.

-- Additional comment from opensource on 2007-07-27 04:52 EST --
(In reply to comment #3)
> Static linking isn't the right answer, though, and is explicitly disallowed per
> the packaging guidelines.  The fact that it's needed in early boot isn't a
> reason to link it statically; instead, it's a reason to get libraries moved to 
> /lib.

I have commited to cvs a change that moves the cryptsetup libraries to /lib.
Here is a list of the packages that need to move their libraries to /lib:

/usr/lib/libgcrypt.so.11 -> libgcrypt
/usr/lib/libpopt.so.0 -> popt (rpm)
/usr/lib/libgpg-error.so.0 -> libgpg-error
Comment 1 Matthias Saou 2007-07-30 09:35:43 UTC 
Not directly related, but especially since the lib is now in /lib, wouldn't it
make sense to disable or remove the static libgpg-error.a library?
Comment 2 Nalin Dahyabhai 2007-07-30 13:26:45 UTC 
The shared library's been moved, but nothing else has...?
Comment 3 Matthias Saou 2007-07-30 13:32:43 UTC 
What I meant is that the packages could stop including the static libraries,
since they're probably not needed by anything anymore. They used to be needed
for statically linking, but since the shared library is now in /lib,
applications which need the library to be available very early in the boot
process should be able to dynamically use it.
Comment 4 Nalin Dahyabhai 2007-07-30 13:42:06 UTC 
Fair enough.  Building with --disable-static starting in -3.