Bug 1009921 - scl-utils: Macro scl_files expands bad on 64 bit architecture if metapackage is noarch
scl-utils: Macro scl_files expands bad on 64 bit architecture if metapackage ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: scl-utils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Zeleny
Fedora Extras Quality Assurance
:
: 988565 1017088 (view as bug list)
Depends On:
Blocks: 1029516 1032452 1040860
  Show dependency treegraph
 
Reported: 2013-09-19 09:42 EDT by Bohuslav "Slavek" Kabrda
Modified: 2014-01-10 02:42 EST (History)
5 users (show)

See Also:
Fixed In Version: scl-utils-20131017-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1029516 (view as bug list)
Environment:
Last Closed: 2013-11-10 02:19:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bohuslav "Slavek" Kabrda 2013-09-19 09:42:03 EDT
If you try to build a noarch metapackage on 64 bit machine, you'll end up with error like this:

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /opt/rh/python27/root/lib64

This is caused by these lines in macros.scl:

%ifarch x86_64 ppc ppc64 sparc sparc64 s390 s390x
%{_scl_root}/%{_lib}
%endif

The problem is, that %ifarch conditionals seems not to expand in %files section. To reproduce this, just write a specfile with %files section like this:

%files
%ifarch <yourarch>
this_file_wont_be_searched_for
%endif

this_file_wont_be_searched_for doesn't exist in BUILDROOT, but RPM raises no error (so this could as well be RPM error, not scl-utils problem).

It'd seem that the same should happen to %{_scl_root}/usr/%{_lib}, which uses the same conditionals, but this is included because there are lots of other directories included inside it, which masks the error.
Comment 1 Jan Zeleny 2013-10-09 04:44:43 EDT
Could you please send me the srpm that caused this? I tried to reproduce the issue, without any success, everything works as expected. Thanks
Comment 2 Bohuslav "Slavek" Kabrda 2013-10-09 06:15:32 EDT
Hmm, strange, I currently can't reproduce this. I'm however not the only one who experienced this problem.
CC @Remi, I know you said you hit this, can you still reproduce?
Comment 3 Remi Collet 2013-10-09 06:29:17 EDT
Take any spec and add

BuildArch: noarch

Try to build on x86_64 computer

/opt/rh/php55/root/lib64 is not listed in %files.
Comment 4 Jan Zeleny 2013-10-09 08:48:19 EDT
(In reply to Remi Collet from comment #3)
> Take any spec and add
> 
> BuildArch: noarch
> 
> Try to build on x86_64 computer
> 
> /opt/rh/php55/root/lib64 is not listed in %files.

Well, yeah, that's why the condition Slavek quoted is there - to avoid creating /lib64 for 32bit and noarch packages. See the package "filesystem", there is the same thing there.

It also kinda makes sense, doesn't it? If you want the package to be noarch, then you don't need /lib64, do you? Maybe I'm wrong but I honestly don't see the use case.

Maybe the problem is elsewhere. Do you install some files into /lib64 manually? Or are they somehow included by the %scl_install macro?
Comment 5 Jan Zeleny 2013-10-09 08:48:54 EDT
*** Bug 988565 has been marked as a duplicate of this bug. ***
Comment 6 Jan Zeleny 2013-10-09 08:51:17 EDT
*** Bug 1017088 has been marked as a duplicate of this bug. ***
Comment 7 Remi Collet 2013-10-09 09:04:06 EDT
Yes, directory is created by %scl_install macro.

So %scl_files and %scl_install are not consistent.


I don't think having noarch metapackage make sense.. but...
https://fedoraproject.org/wiki/User:Bkabrda/SCLGuidelinesDraft
Comment 8 Jan Zeleny 2013-10-09 09:22:55 EDT
Thanks Remi, the fix is coming.
Comment 9 Bohuslav "Slavek" Kabrda 2013-10-10 01:58:32 EDT
Just for reference, there is a related post on Fedora devel ML from Spot: https://lists.fedoraproject.org/pipermail/devel/2013-October/190036.html
Comment 10 Fedora Update System 2013-10-16 03:42:44 EDT
scl-utils-20131015-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-20131015-1.fc20
Comment 11 Fedora Update System 2013-10-16 03:43:16 EDT
scl-utils-20131015-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/scl-utils-20131015-1.fc19
Comment 12 Jan Zeleny 2013-10-16 06:32:48 EDT
The "updated update" is here:
https://admin.fedoraproject.org/updates/scl-utils-20131016-1.fc19
Comment 13 Jan Zeleny 2013-10-17 10:22:44 EDT
While testing on real-life collections I found one unrelated issue in scl-utils, a new update has been issued:

https://admin.fedoraproject.org/updates/scl-utils-20131017-1.fc19
Comment 14 Fedora Update System 2013-10-17 16:32:44 EDT
Package scl-utils-20131017-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing scl-utils-20131017-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19205/scl-utils-20131017-1.fc20
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2013-11-10 02:19:26 EST
scl-utils-20131017-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2014-01-10 02:42:23 EST
scl-utils-20131017-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

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