Bug 127554 - Unresolvable chain of dependencies: ppp-2.4.2-3.FC2.1
Summary: Unresolvable chain of dependencies: ppp-2.4.2-3.FC2.1
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
: 127592 127668 127696 (view as bug list)
Depends On: 127603
Blocks: FC2Update
TreeView+ depends on / blocked
Reported: 2004-07-09 17:25 UTC by Pascal Volk
Modified: 2007-11-30 22:10 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-07-23 08:02:21 UTC

Attachments (Terms of Use)
Patch to fix 'Provides' in ppp.spec (1.17 KB, patch)
2004-07-09 23:53 UTC, Pascal Volk
no flags Details | Diff

Description Pascal Volk 2004-07-09 17:25:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

Description of problem:
I've tried to run `up2date -u` to become the last ppp-rpm. But there
is a unresolvable chain of dependencies:

--- 8< snip ---
Fetching rpm headers...

Name                                    Version        Rel     
ppp                                     2.4.2          3.FC2.1       

Testing package set / solving RPM inter-dependencies...
There was a package dependency problem. The message was:

Unresolvable chain of dependencies:
initscripts-7.53-1                       requires pppd < 2.3.9

--- snap >8 ---

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

How reproducible:

Steps to Reproduce:
1. open xterm
2. type up2date -u
3. wait ...

Actual Results:  I can't update the ppp-rpm

Additional info:

Comment 1 Sean Bruno 2004-07-09 18:29:52 UTC
This is happening to me as well via yum:

[sean@homebox sean]$ sudo yum -y update
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]$

Comment 2 Nils Philippsen 2004-07-09 21:12:12 UTC
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 ;-).

Comment 3 Pascal Volk 2004-07-09 23:53:31 UTC
Created attachment 101774 [details]
Patch to fix 'Provides' in ppp.spec

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

Comment 4 Thomas Chung 2004-07-10 08:53:44 UTC
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:


Thomas Chung

Comment 5 Nils Philippsen 2004-07-10 11:46:02 UTC
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

Comment 6 Nils Philippsen 2004-07-10 11:47:58 UTC
As I see it, this is a problem with automatically determined Provides,
i.e. rpmbuild.

Comment 7 Nils Philippsen 2004-07-10 12:26:34 UTC
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:.

Comment 8 Matthew Miller 2004-07-10 16:55:55 UTC
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 ***

Comment 9 Nils Philippsen 2004-07-11 10:46:55 UTC
Reopened because solving 123697 doesn't automatically solve this
issue, the package needs to be rebuilt then.

Comment 10 Thomas Woerner 2004-07-12 10:12:25 UTC
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.

Comment 11 Thomas Woerner 2004-07-12 10:13:20 UTC
*** Bug 127592 has been marked as a duplicate of this bug. ***

Comment 12 Thomas Woerner 2004-07-12 13:11:13 UTC
*** Bug 127668 has been marked as a duplicate of this bug. ***

Comment 13 Michael Schwendt 2004-07-12 19:04:56 UTC
*** Bug 127696 has been marked as a duplicate of this bug. ***

Comment 14 Nils Philippsen 2004-07-13 08:00:49 UTC
FYI: new initscript package has been announced which fixes the pppd
<-> ppp typo, so everything should be fine for end users by now.

Comment 15 Matthias Saou 2004-07-22 19:04:27 UTC
Yes, it has been fixed. Why is this bug still opened? :-)

Comment 16 Thomas Woerner 2004-07-23 08:02:21 UTC
Closing this bug...

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