Bug 133778 - libgcc predepends on something it provides itself
Summary: libgcc predepends on something it provides itself
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-27 12:39 UTC by Dag Wieers
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 00:14:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Dag Wieers 2004-09-27 12:39:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803 Galeon/1.3.17

Description of problem:
Apt complains with this error:

  E: Couldn't configure pre-depend /usr/sbin/libgcc_post_upgrade for
libgcc, probably a dependency cycle.

While indeed:

  [dag@horsea dag]$ rpm -qR libgcc
  rpmlib(PayloadFilesHavePrefix) <= 4.0-1
  rpmlib(CompressedFileNames) <= 3.0.4-1


  [dag@horsea dag]$ rpm -qf /usr/sbin/libgcc_post_upgrade  


  [dag@horsea dag]$ rpm -q --scripts libgcc
  postinstall program: /usr/sbin/libgcc_post_upgrade

This may be in fact an apt bug, still it seems strange to me that a
package depends on a file it provides itself. So I would get rid of
the dependency anyway.

My workaround is to create that file, but this is something that
breaks an upgrade from Red Hat 7.3 to Red Hat EL3.

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

How reproducible:

Steps to Reproduce:
1. ..

Additional info:

Comment 1 Jakub Jelinek 2004-09-28 08:11:46 UTC
That is an apt bug then.
This dependency is not explicitely in gcc (or glibc) spec file,
rpm adds it automatically when it sees a scriptlet.

Comment 2 Jeff Johnson 2004-09-28 12:01:25 UTC
Yes, apt-rpm bug.

rpm does not distinguish between PreReq: and Requires:,
the two are synonyms, treated exactly the same.
This is rpm behavior since RHL 6.2.

Comment 3 Jeff Johnson 2004-09-28 14:49:35 UTC
FWIW, Gustavo sez' that the apt-rpm in use here is
deviant from what he uses. You might want to check
what apt-rpm you are using.

Comment 4 Dag Wieers 2004-09-28 15:38:38 UTC
Ok, I verified this and contrary to what I believed it indeed was a
very dated: apt-0.5.4cnc9-1.dag.rh73.i386.rpm

Sorry for that and thanks for the prompt replies.

Still I'm wondering if it would make sense to change RPM so it
wouldn't add these requirements if the package itself provides it and
eg. it is required by a %post or %preun script.

It would probably save some diskspace, bandwidth, memory and CPU
cycles if both RPM and apt/yum does not have to handle that. Maybe
something that can quickly be checked what the overhead is. 

A quick biased example, the perl package has 194 dependencies, of
which 188 point to its own package !

I reopened this bug and changed severity to 'enhancement' in order to
re-evaluate the changed focus of this bug. In case a new bugreport is
required or you just want me to shut up, please close again :)

Comment 5 Jeff Johnson 2004-09-30 00:14:30 UTC
(digest from irc discussion)

While it may seem to make no sense from a package POV
that /usr/bin/perl has
    Provides: perl <= 3:5.8.5
while the horde of included *.pl modules have myriad
    Requires: perl >= 0: 5
and many more, the rationale for not automagically
reducing the package dependencies by checking for
overlapping ranges and choosing the broadest range
is that, in fact, the Provides: and Requires: are attached
to different objects within the package, the Provides:
from /usr/bin/perl (and other elements), while the Requires:
are as specified (and automagically extracted) in various
*.pl scripts within.

The elements are different, and rpm can do no more than
carry the dependencies as specified by the packager.

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