Bug 349801 - mock installs packages that don't satisfy BuildRequires:
mock installs packages that don't satisfy BuildRequires:
Status: CLOSED WORKSFORME
Product: Fedora Infrastructure
Classification: Retired
Component: extras buildsys (Show other bugs)
unspecified
All Linux
medium Severity high
: ---
: ---
Assigned To: Seth Vidal
Jeremy Katz
: Reopened
Depends On:
Blocks: 214967
  Show dependency treegraph
 
Reported: 2007-10-23 21:23 EDT by Dominik 'Rathann' Mierzejewski
Modified: 2014-01-21 17:59 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-16 14:01:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dominik 'Rathann' Mierzejewski 2007-10-23 21:23:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5

Description of problem:
When trying to build arpack, which has
BuildRequires: %{_libdir}/liblapack.so
mock finds that atlas-devel satisfies that BR, when it doesn't. At least, according to yum resolvedep on F-7:
yum resolvedep /usr/lib64/liblapack.so
Loading "basearchonly" plugin
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
Importing additional filelist information
0:lapack-devel-3.1.1-1.fc7.x86_64

Fails consistently for dist-f9, dist-f8-updates-candidate and dist-fc7-updates-candidate scratch builds:
http://koji.fedoraproject.org/koji/taskinfo?taskID=208665
http://koji.fedoraproject.org/koji/taskinfo?taskID=208688
http://koji.fedoraproject.org/koji/taskinfo?taskID=208682

Version-Release number of selected component (if applicable):
whatever is running on koji

How reproducible:
Always


Steps to Reproduce:
1. wget http://rathann.fedorapeople.org/review/arpack-2.1-7.fc7.src.rpm
2. koji build --scratch dist-f9 arpack-2.1-7.fc7.src.rpm


Actual Results:
Build fails with:
/usr/bin/ld: cannot find -llapack

Expected Results:
arpack should build successfully, as it does for local builds with lapack-devel installed.


Additional info:
Comment 1 Jesse Keating 2007-10-23 22:23:21 EDT
This looks like it could possibly be a bug in FC6 yum, which is what mock uses
to resolve the deps.

We will be investigating this.  In the mean time a workaround would be to setup
an %if structure to buildrequire the actual package name for Fedora and for RHEL.

http://fedoraproject.org/wiki/Packaging/DistTag has info on how you can do this.
Comment 2 James Antill 2007-11-21 14:54:31 EST
 This is fixed in Fedora 7 onwards.
Comment 3 Dominik 'Rathann' Mierzejewski 2007-11-21 15:11:14 EST
Yes, but I'm the buildsys is still running FC6 and that is the problem, so
please don't just close the bug like that. I cannot upgrade the OS which is
running on the buildsys, so this bug remains open as far as I'm concerned,
because it prevents us from building a perfectly valid package.
Comment 4 Dominik 'Rathann' Mierzejewski 2007-12-30 08:12:23 EST
The bug is still present, please fix it already...

http://koji.fedoraproject.org/koji/taskinfo?taskID=315488

Why don't you just update buildsys' mock?
Comment 5 Dominik 'Rathann' Mierzejewski 2007-12-30 08:15:59 EST
In reply to comment #4)
> Why don't you just update buildsys' mock?

I meant, of course, yum.
Comment 6 Dominik 'Rathann' Mierzejewski 2007-12-30 08:19:58 EST
Reassigning to infrastructure and bumping up severity. This is preventing a new,
perfectly valid package from entering Fedora.
Comment 7 Dominik 'Rathann' Mierzejewski 2008-01-06 11:45:38 EST
Cc'ing Axel. It's his package that trigger this problem.
Comment 8 Axel Thimm 2008-01-26 03:22:59 EST
FC6 is EOL, and yum development usually does not support too old yum versions.
Could we please get a newer yum on the builders? Or maybe a backport of the fix
to the yum version used there? Thanks!
Comment 9 Michael E Brown 2008-01-26 17:14:08 EST
the entire buildsys was updated to RHEL5 in early december: mock 0.9, yum 3.0

Has this been confirmed to still be a problem?
Comment 10 Jason Tibbitts 2008-01-29 13:06:49 EST
Yes, it still seems to be a problem to me.  (I happen to really need arpack.)

See the following task: http://koji.fedoraproject.org/koji/taskinfo?taskID=381895

This builds fine in local mock (mock 0.9.5 running on Fedora 8, the build is
against rawhide) but in koji it fails. The important difference is in root.log:
on my system, mock (or yum, I guess) figures out that it needs to install
lapack-devel to satisfy the dependency on liblapack.so; in koji, it doesn't.

Note the following in the spec, though:

# The correct dependency would be the following, but it doesn't exist on RHEL4/3
#BuildRequires: lapack-devel
BuildRequires: %{_libdir}/liblapack.so

This trouble could probably be worked around simply by conditionalizing the
BuildRequires:, or just not using the same spec on RHEL4.
Comment 11 Axel Thimm 2008-01-29 17:15:49 EST
(In reply to comment #9)
> the entire buildsys was updated to RHEL5 in early december: mock 0.9, yum 3.0
> 
> Has this been confirmed to still be a problem?

Yes, shortly before posting comment #8.

(In reply to comment #10)
> This trouble could probably be worked around simply by conditionalizing the
> BuildRequires:, or just not using the same spec on RHEL4.

Not really, we are just seeing an implementation of some bug that seems to
invent provides of a package where there are none. Papering over the triggering
case will not make the bug go away, on the contrary we do need this package in
the form it is, not just because it is written correctly, but because otherwise
you will need to wait for some other package to trigger this bug.

E.g. Michael, if you do have direct access to the buildsys then please use this
package to diagnose yum and friends on why they decide to do things differently
there than in our local setups. Thanks!
Comment 12 Jason Tibbitts 2008-02-14 22:34:13 EST
It's still hilarious that this hasn't been built yet when the workaround is
trivial; not having this built serves no useful purpose and merely blocks other
packages from entering the distro (and screws me into having to maintain the
packages in a local distro for no rational reason whatsoever).  People know that
some updates need to be made on the builders but this requires coordination and
maintainer time, while the workaround requires essentially no time from anyone.
 The fixes will happen in the course of time anyway so the thought that leaving
arpack unbuilt somehow places pressure on someone to revise the update schedule
is ludicrous.

However, I heard that some updates were occurring on the builders today and I
did a scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=428390

It succeeded on one host but failed on another; I asked for the yum versions on
the relevant hosts and was told that ppc4 has yum-3.2.8-6.el5 while ppc3 has
only yum-3.0.1-5.el5.  With luck the other builders will be likewise updated and
this sad saga can come to a close.
Comment 13 Jason Tibbitts 2008-02-16 14:01:14 EST
All of the builders have been updated; arpack builds fine now:

http://koji.fedoraproject.org/koji/taskinfo?taskID=432108

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