Bug 169288 - krbafs should own /usr/lib/libkrbafs.so.?
krbafs should own /usr/lib/libkrbafs.so.?
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: krbafs (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-26 13:07 EDT by Ralf Corsepius
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.2.2-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 13:52:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2005-09-26 13:07:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.5.2

Description of problem:
The krbafs rpm owns /usr/lib/libkrbafs.so.0.0.0, but doesn't ship nor own the corresponding /usr/lib/libkrbafs.so.0 symlink.




Version-Release number of selected component (if applicable):
krbafs-1.2.2-7

How reproducible:
Always

Steps to Reproduce:
1. yum install krbafs
2. rpm -qf /usr/lib/libkrbafs.so.*


Actual Results:  # rpm -qf /usr/lib/libkrbafs.so.0*
file /usr/lib/libkrbafs.so.0 is not owned by any package
krbafs-1.2.2-7


Expected Results:  The krbafs rpm should be shipped with the corresponding
/usr/lib/libkrbafs.so.0


Additional info:
Comment 1 Nalin Dahyabhai 2005-09-27 18:02:16 EDT
The link is created and cleaned up by ldconfig. I'm inclined to let it do its
job, so marking wontfix.
Comment 2 Ralf Corsepius 2005-09-27 21:50:17 EDT
(In reply to comment #1)
> The link is created and cleaned up by ldconfig. I'm inclined to let it do its
> job, so marking wontfix.

I am speechless. If your package was an FE package, I now would veto against it.
Comment 3 Michael Schwendt 2005-09-28 07:33:24 EDT
It is a packaging mistake with at least the following rationale
(I've been through this with another developer at Red Hat before):

   $ rpm --query --provides krbafs
   config(krbafs) = 1.2.2-8
   libkrbafs.so.0  
   krbafs = 1.2.2-8

As you can see, the package contains a "virtual provides" for the SONAME
libkrbafs.so.0, which will only exist after package installation _if_
ldconfig really creates the necessary symlink. Under no circumstances
should ldconfig fail to create the symlink. If it doesn't create it,
the "virtual provides" is wrong, and something is broken. Hence the
symlink belongs into the package, also to ensure that verifying the
package works, too.

Apart from that, creating the symlink within the spec file can be done
with ldconfig, too.
Comment 4 Nalin Dahyabhai 2005-09-28 11:03:38 EDT
(In reply to comment #3)
> It is a packaging mistake with at least the following rationale
> (I've been through this with another developer at Red Hat before):
> 
>    $ rpm --query --provides krbafs
>    config(krbafs) = 1.2.2-8
>    libkrbafs.so.0  
>    krbafs = 1.2.2-8
> 
> As you can see, the package contains a "virtual provides" for the SONAME
> libkrbafs.so.0, which will only exist after package installation _if_
> ldconfig really creates the necessary symlink. Under no circumstances
> should ldconfig fail to create the symlink. If it doesn't create it,
> the "virtual provides" is wrong, and something is broken. Hence the
> symlink belongs into the package, also to ensure that verifying the
> package works, too.

So is this done because it's expected that ldconfig will fail, or is there
confusion between the soname which the package provides and the pathname of the
symlink (%{_libdir}/libkrbafs.so.0)?  I'm not trying to be combative, I'm just
having some trouble understanding why it's necessary.  Being able to verify the
contents of the link is useful, but then the link isn't exactly a configuration
file.
Comment 5 Ralf Corsepius 2005-09-28 13:34:20 EDT
(In reply to comment #4)

> So is this done because it's expected that ldconfig will fail, or is there
> confusion between the soname which the package provides and the pathname of the
> symlink (%{_libdir}/libkrbafs.so.0)?  I'm not trying to be combative,
> I'm just having some trouble understanding why it's necessary.

1. Your packaging leaves unowned files on the file system and causes
inconsistencies between the state on the file system and the rpmdb.

2. Your packaging is unsafe: It does not guarantee the symlink to be generated:
# rpm -U --noscripts krbafs-1.2.2-7.i386.rpm
# ls -l libkrbafs*
-rwxr-xr-x  1 root root 19872 Mar 16  2005 libkrbafs.so.0.0.0

3. A common means to verify completeness of a package, esp. in case of system
damage is to use "rpm -qV <package>". As the symlink is not contained in the
rpmdb you prevent users from verifying completeness of your package.

4. What you do contradicts to what is common standard in almost all FC packages,
is regarded mandatory in FE packaging conventions and is common practice in
almost all rpm-based Linux distributions.

....

=> All in all, your packaging adds avoidable unsafety, confusion and contributes
to a lack of usability.
Comment 6 Michael Schwendt 2005-09-28 13:39:18 EDT
> So is this done because it's expected that ldconfig will fail,
> or is there confusion between the soname which the package provides
> and the pathname of the symlink (%{_libdir}/libkrbafs.so.0)? 

Huh? Neither one.

It's because at run-time only %_libdir/libkrbafs.so.0 actually
causes the provided SONAME to be found by the dynamic linker.
Hence that symlink belongs into the package. The symlink is an
essential part of the package.

As a beneficial side-effect, "rpm -qf /usr/lib/libkrbafs.so.0"
will not return crap.


Instead of being stubborn, how about you come up with a good
reason why you think the symlink should not be included and
not even %ghost'ed in the package? Personally, I believe the
reason given in comment 1 is a poor excuse.
Comment 7 Nalin Dahyabhai 2005-09-28 13:52:43 EDT
(In reply to comment #6)
> Instead of being stubborn, how about you come up with a good
> reason why you think the symlink should not be included and
> not even %ghost'ed in the package? Personally, I believe the
> reason given in comment 1 is a poor excuse.

I'm not trying to be stubborn.  I'm trying to gain a better understanding of
things.  Please don't read into my words motive which I've explicitly stated
isn't there.

At any rate, you had me convinced at package verification.  Closing.

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