Bug 169288

The link is created and cleaned up by ldconfig. I'm inclined to let it do its
job, so marking wontfix.

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

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.

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

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

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

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