When building an SCL, each package of the SCL have (automatically added) Requires: php-runtime 1/ this should be arched (I think this is a bug) Requires: php-runtime%{_isa} Else, mixing various arch package will raise various unwanted issue. 2/ RFE make this "vendor" aware If 2 vendor rebuild the same collections foo from bar1, using /opt/bar1/foo foo from bar2, using /opt/bar2/foo Packages from both build can be mixed, but won't work. This could be forbiden at install time, having a vendor aware virtual. Ex: in foo-runtime Provides: foo-runtime(%{vendor}) Provides: foo-runtime(%{vendor})%{_isa} And in each arched package of the collection Requires: foo-runtime(%{vendor})%{_isa} of in noarch packages Requires: foo-runtime(%{vendor}) This will give guaranty that all installed package of the collection will be provided by the same "vendor". Of course, this can also be solved having package prefixed by vendor %scl_prefix => %{scl_vendor}-%{scl}-
Remi, I'd like you to elaborate on a few things so I understand your request better. I'm mostly curious about reasons of your requests, i.e. the background and reasons why do you want all these things to be done (or maybe what use cases are broken with the current state). For instance, your request to include architecture information: the provide is there only for informational purposes (scl --list php), at least that's its intended usage. Including architecture information doesn't really make much sense there, or at least I don't see the use case. Thanks for any additional info you give me
Scratch the second paragraph, I mistook scl-package() with scl-runtime(). In any case, runtime packages should be noarch by definition so if you have an example where it's not noarch, it will definitely help.
Have you an example of -runtime being noarch ? From any enable script (I've check python27 one) export LD_LIBRARY_PATH=%{_libdir}... Please explain how this can be noarch ?
Good example and good point. I guess I have some ancient versions of spec files on my machine. Arch now makes more sense. While I still don't quite see how can you mix the two architectures under normal circumstances, I take your request into account and will update the behavior at the earliest opportunity to contain the architecture.
Another issue with this auto added Requires. It is added on the last sub-package... so often on the debuginfo... $ for i in *rpm; do echo "PACKAGE $i"; rpm -qp --requires $i | grep runtime; done PACKAGE php54-php-pecl-http-2.1.1-1.fc19.remi.src.rpm PACKAGE php54-php-pecl-http-2.1.1-1.fc19.remi.x86_64.rpm PACKAGE php54-php-pecl-http-debuginfo-2.1.1-1.fc19.remi.x86_64.rpm php54-runtime PACKAGE php54-php-pecl-http-devel-2.1.1-1.fc19.remi.x86_64.rpm Not very useful ;) So for now, I prefer to switch to manual added dependencies, waiting for an upstream fix.
That's odd, I specifically remember Albert designing it to affect all the packages that actually have some content and the metapackages, so both the metapackage and the -devel subpackage should have the dependency as well. Could you send me a link to the srpm you are using to build the packages in question? I will take a look where the bug might be.
As for now we cannot import SCL spec in Fedora :( all are hosted in my personnal repo. Some examples (all my spec for php extensions are SCL aware) https://github.com/remicollet/remirepo/tree/master/scl-php56/php56 (main package) https://github.com/remicollet/remirepo/tree/master/php/pecl/php-pecl-http (generic spec, arched extension) https://github.com/remicollet/remirepo/tree/master/php/pear/php-pear (generic spec, noarch library) ... If you prefer SRPM: http://rpms.famillecollet.com/SRPMS/?C=M;O=D
Just out of curiosity, which version of scl-utils are you using? There is an update in koji but it has not been submitted to non-rawhide Fedoras yet.
(In reply to Jan Zeleny from comment #8) > Just out of curiosity, which version of scl-utils are you using? There is an > update in koji but it has not been submitted to non-rawhide Fedoras yet. scl-utils-20140815-1.fc21.x86_64 scl-utils-20140127-5.fc20.x86_64 scl-utils-20140127-5.fc19.x86_64 scl-utils-20130529-5.el7.x86_64 scl-utils-20120927-8.el6.x86_64
Ok, so it's basically every release available ... that's weird, the behavior differs significantly in all those releases ... anyway, I'll take a look, thanks.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.