This is happening to me as well via yum:

[sean@homebox sean]$ sudo yum -y update
Password:
Gathering header information file(s) from server(s)
Server: Fedora Core 2 - i386 - Base
Server: Fedora Core 2 - i386 - Released Updates
Finding updated packages
Downloading needed headers
Resolving dependencies
.conflict between initscripts and pppd
[sean@homebox sean]$

The problem is that ppp provides "pppd" and initscripts-7.53-1
conflicts with "pppd < 2.3.9". I don't know why ppp provides pppd in
the first place -- it isn't mentioned anywhere in the spec file, I can
only guess that this is a problem in find-provides or so. Leaving that
aside, initscripts should just conflict with "ppp < 2.3.9" instead ;-).

Created attachment 101774 [details]
Patch to fix 'Provides' in ppp.spec

The attached patch solves the problem. It was the missing version from the
pppd-binary.

Please leave this bug report open until the packager maintainer
offically releases a new update.

We'll be monitoring this bug report from our Fedora Advisory page:

http://fedoranews.org/updates/FEDORA-2004-214.shtml

Thomas Chung
FeodraNEWS.ORG

The attached patch might hide the problem, but doesn't solve it -- a
normal binary shouldn't be a Provides: without a path.
CLOSED/WORKSFORME is for maintainers to close bugs which cannot be
reproduced.

As I see it, this is a problem with automatically determined Provides,
i.e. rpmbuild.

Hmm, too quick. The problem is not in rpmbuild or in the find-provides
script, but that both /usr/sbin/chat and /usr/sbin/pppd get detected
as sharefd objects and not executables:

nils@gibraltar:~> file /var/tmp/ppp-root/usr/sbin/*
/var/tmp/ppp-root/usr/sbin/chat:     ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), stripped
/var/tmp/ppp-root/usr/sbin/pppd:     ELF 32-bit LSB shared object,
Intel 80386, version 1 (SYSV), stripped
/var/tmp/ppp-root/usr/sbin/pppdump:  ELF 32-bit LSB executable, Intel
80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses
shared libs), stripped
/var/tmp/ppp-root/usr/sbin/pppstats: ELF 32-bit LSB executable, Intel
80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses
shared libs), stripped

Now I think that the problem is PIE executables which get erroneously
detected as shared objects and not as executables leading
find-provides to list them as Provides:.

This is a duplicate of bug #123680 (the initscripts typo) and
therefore of bug #123697 (the PIE fix).

*** This bug has been marked as a duplicate of 123697 ***

Reopened because solving 123697 doesn't automatically solve this
issue, the package needs to be rebuilt then.

This is eiter an find-provides (rpm) or a file problem:

find-provides is using this to search for libraries:
   solist=$(echo $filelist | grep "\\.so" | grep -v "^/lib/ld.so" | \
   	xargs file -L 2>/dev/null | grep "ELF.*shared object" | cut
   -d: -f1)

But file considers pppd, which is a PIE binary, to be a shared library:
   $ file pppd
   pppd: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), 
   not stripped

find-provides can easily be fixed:
   # --- Library sonames and weak symbol versions (from glibc).
   for f in $solist; do
   +    eu-readelf -d $f | egrep -q '  DEBUG[[:space:]]*$' && continue
But then rpm would require elfutils.

Assigning to rpm.


In the meantime I will build a new ppp for FC2 without PIE support.

*** Bug 127592 has been marked as a duplicate of this bug. ***

*** Bug 127668 has been marked as a duplicate of this bug. ***

*** Bug 127696 has been marked as a duplicate of this bug. ***

FYI: new initscript package has been announced which fixes the pppd
<-> ppp typo, so everything should be fine for end users by now.

Yes, it has been fixed. Why is this bug still opened? :-)

Closing this bug...