Bug 1139209 - SCL consistency, Requires: php-runtime
Summary: SCL consistency, Requires: php-runtime
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: scl-utils
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ľuboš Kardoš
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-08 11:57 UTC by Remi Collet
Modified: 2016-08-01 01:27 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 12:06:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Remi Collet 2014-09-08 11:57:26 UTC
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}-

Comment 1 Jan Zeleny 2014-09-08 12:58:43 UTC
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

Comment 2 Jan Zeleny 2014-09-08 13:18:53 UTC
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.

Comment 3 Remi Collet 2014-09-08 13:24:27 UTC
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 ?

Comment 4 Jan Zeleny 2014-09-08 14:13:02 UTC
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.

Comment 5 Remi Collet 2014-09-09 09:10:04 UTC
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.

Comment 6 Jan Zeleny 2014-09-09 10:43:59 UTC
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.

Comment 7 Remi Collet 2014-09-09 12:15:45 UTC
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

Comment 8 Jan Zeleny 2014-09-09 14:07:25 UTC
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.

Comment 9 Remi Collet 2014-09-09 14:15:32 UTC
(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

Comment 10 Jan Zeleny 2014-09-09 14:19:02 UTC
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.

Comment 11 Jaroslav Reznik 2015-03-03 16:16:43 UTC
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

Comment 12 Fedora Admin XMLRPC Client 2016-05-30 14:58:55 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Fedora End Of Life 2016-07-19 12:06:38 UTC
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.


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