Description of problem: We solved conflicts of installation into standart path, but we didn't solve conflicts of name of packages. Use-case: ruby193 exists in RHSCL, but there also exists ruby193 in Satelite. Problem: There was missing policy for using prefixes. Satelite 6 rebuild the existing collection with same prefix, which was already used in RHSCL. Those two products might have conflicting packages. Customers might have similar issues. New policy: * Internal projects must use their own prefix. For example satelite6-foreman instead of ruby193-foreman. * External customers will use their own prefix in names of a collection. Let's say IBM will use installation: path /opt/ibm and prefix will be ibm_ruby193. Version-Release number of selected component (if applicable): Actual results: The prefix now contains /opt/rh. rh can't be modify easily. Expected results: Vendor should be a part of macro, which might be changed easily by customer. Also it must be possible to use the same macro to create installation path: /opt/vendor/vendor_ruby193-ruby I'm not sure if_ or - is better, the important thing is to have the vendor macro definition outside of the prefix string. Additional info: %vendor macro is already used, let's use eg. scl_vendor_prefix or something like that.
*** Bug 985336 has been marked as a duplicate of this bug. ***
So, there are users, who installs in /something instead of /opt/something. We need to make even the opt part configurable. Could you split it into two macros and do them configurable?
To be perfectly honest, this request doesn't make much sense to me in the context of this bug. The sole purpose of this bug was to limit the possibilities for users so that the collections are all at one place. Your request now goes directly the other way. If you want to do such a thing, why would you want to split the prefix macro in the first place?
You might be right it's not needed to change anything, but we definitely need documentation. I redefined %{!?_scl_prefix: %global _scl_prefix /something/scl} Then I tried rebuild metapackage of Perl. I created in install section the /something/scl directory. It failed on: echo "%lang(${locale}) /something/scl/perl516/root/usr/share/locale/${locale}" >> $RPM_BUILD_DIR/%{buildsubdir}/filesystem What else should I define?
I'm not aware of anything else that needs to be changed. Could you send me a link to the metapackage so I can do some debugging?
Hm, maybe I have wrong understanding of what you have done/how you have tested the macro, I just added this line to the spec file you sent me: %global _scl_prefix /tmp/scl Rebuilding the metapackage went fine and the content is indeed in the specified directory. That leads me to a conclusion that you must have done something else besides adding the line there. Looking at your comment 6, I have to admit that I have a hard time processing your description but I hope this comment will clear things out.
My proposal to solve this: %{!?scl_path:%global %scl_path /opt} %{!?scl_vendor:%global %scl_vendor rh} %{!?_scl_prefix?: %global %_scl_prefix %{scl_path}/%{scl_vendor} (The macros names may differ, but I think that this generally is what we need/want to solve various usecases.)
(In reply to Bohuslav "Slavek" Kabrda from comment #10) > My proposal to solve this: > > %{!?scl_path:%global %scl_path /opt} > %{!?scl_vendor:%global %scl_vendor rh} > %{!?_scl_prefix?: %global %_scl_prefix %{scl_path}/%{scl_vendor} > > (The macros names may differ, but I think that this generally is what we > need/want to solve various usecases.) That's actually exactly what I have prepared for upstream. But as you can see, it proves my previous point. The entire reason for splitting the macro in two was to fixate the first part of the prefix and offer only the vendor as configurable part. Once you make it all configurable, there is no added value whatsoever, only more ways to configure the prefix which is just confusing.
(In reply to Jan Zeleny from comment #9) > Hm, maybe I have wrong understanding of what you have done/how you have > tested the macro, I just added this line to the spec file you sent me: > > %global _scl_prefix /tmp/scl > > Rebuilding the metapackage went fine and the content is indeed in the > specified directory. That leads me to a conclusion that you must have done > something else besides adding the line there. Looking at your comment 6, I > have to admit that I have a hard time processing your description but I hope > this comment will clear things out. For the record, this has been tracked down to missing %setup in the %prep part of the spec file in question.
(In reply to Jan Zeleny from comment #11) > (In reply to Bohuslav "Slavek" Kabrda from comment #10) > > My proposal to solve this: > > > > %{!?scl_path:%global %scl_path /opt} > > %{!?scl_vendor:%global %scl_vendor rh} > > %{!?_scl_prefix?: %global %_scl_prefix %{scl_path}/%{scl_vendor} > > > > (The macros names may differ, but I think that this generally is what we > > need/want to solve various usecases.) > > That's actually exactly what I have prepared for upstream. But as you can > see, it proves my previous point. The entire reason for splitting the macro > in two was to fixate the first part of the prefix and offer only the vendor > as configurable part. Once you make it all configurable, there is no added > value whatsoever, only more ways to configure the prefix which is just > confusing. Not true. Once you make this all configurable, you allow users to: - just change vendor, but leave the rest of _scl_prefix be defined by scl-utils - just change path (/opt to something else), leaving the vendor be defined by scl-utils - change the whole _scl_prefix macro to anything without having to care about path/vendor (also, this would guarantee backwards compat for current users of scl-utils, who change _scl_prefix to build e.g. non-rh collections)
Thank you for proving my point yet again. You get more options, yes. But you don't get anything *extra* - it's just a change for the sake of change, the set of things you can do will remain exactly the same. More than that, there is also added confusion which always comes when you have multiple overlapping ways to do the same thing. Bottom line, if the "fully configurable" requirement doesn't go away, I will close this bug again, as the intention here has clearly shifted.
(In reply to Jan Zeleny from comment #14) > Thank you for proving my point yet again. You get more options, yes. But you > don't get anything *extra* - it's just a change for the sake of change, the > set of things you can do will remain exactly the same. More than that, there > is also added confusion which always comes when you have multiple > overlapping ways to do the same thing. By providing just _scl_prefix macro, you force packagers to redefine the *the whole path* even when they just want to change the vendor. That is wrong by design: - Why should I, as a packager, care where the default path for collections is? I only want to say that my vendor is different from "rh". - If upstream location changes from /opt/rh to something else for a good reason, my collections will still build for my _scl_prefix redefinition. If I'm allowed to just specify vendor name, I just need to rebuild and everything will get in place automatically. As for the confusion over multiple overlapping thing: As long as you clearly state the reasoning why they're overlapping, I think it's not a problem. E.g. you should use _scl_prefix if you want to completely override the "format of the path" (e.g. something different than scl-utils generic /path/vendor), override _scl_prefix, otherwise override scl_path and/or scl_vendor. So yes, you *do* get something extra.
Created attachment 830271 [details] split _scl_prefix macro
This patch should be the correct solution. We need to be able set the installation directory, because not all users are using /opt for installation of 3rd party software. Split _scl_prefix macro into two parts - scl_basedir - set /opt or other directory - scl_vendor - set vendor or user in some cases Both macros can be redefined here in macros file by vendors or locally in specfiles.
The patch is not necessary, there already was a patch upstream that I reverted. I'll probably just revert/extend the reversion.
If we go this way, the %{scl_vendor} should not have default value and every collection have to specify it explicitly. Otherwise, everybody will place their collections into /opt/rh which will look like RH is maintaining the collection, which is not the case.
scl-utils-20140108-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/scl-utils-20140108-1.fc19
scl-utils-20140108-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scl-utils-20140108-1.fc20
Package scl-utils-20140108-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing scl-utils-20140108-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-0600/scl-utils-20140108-1.fc19 then log in and leave karma (feedback).
scl-utils-20140127-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/scl-utils-20140127-1.fc19
scl-utils-20140127-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/scl-utils-20140127-1.fc20
scl-utils-20140127-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
scl-utils-20140127-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.