Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 985233 - split prefix macro in two parts
Summary: split prefix macro in two parts
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: scl-utils
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jan Zeleny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 985336 (view as bug list)
Depends On: 985336
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-17 06:58 UTC by Marcela Mašláňová
Modified: 2014-03-01 14:13 UTC (History)
5 users (show)

Fixed In Version: scl-utils-20140127-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 985336 (view as bug list)
Environment:
Last Closed: 2014-03-01 14:05:50 UTC


Attachments (Terms of Use)
split _scl_prefix macro (deleted)
2013-11-28 14:40 UTC, Marcela Mašláňová
no flags Details | Diff

Description Marcela Mašláňová 2013-07-17 06:58:26 UTC
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.

Comment 3 Jan Zeleny 2013-11-14 14:39:18 UTC
*** Bug 985336 has been marked as a duplicate of this bug. ***

Comment 4 Marcela Mašláňová 2013-11-15 14:19:26 UTC
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?

Comment 5 Jan Zeleny 2013-11-15 15:16:23 UTC
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?

Comment 6 Marcela Mašláňová 2013-11-18 09:34:51 UTC
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?

Comment 7 Jan Zeleny 2013-11-18 09:51:14 UTC
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?

Comment 9 Jan Zeleny 2013-11-18 12:41:38 UTC
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.

Comment 10 Bohuslav "Slavek" Kabrda 2013-11-18 13:48:16 UTC
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.)

Comment 11 Jan Zeleny 2013-11-18 14:57:00 UTC
(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.

Comment 12 Jan Zeleny 2013-11-18 15:13:08 UTC
(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.

Comment 13 Bohuslav "Slavek" Kabrda 2013-11-19 07:14:38 UTC
(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)

Comment 14 Jan Zeleny 2013-11-19 08:00:46 UTC
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.

Comment 15 Bohuslav "Slavek" Kabrda 2013-11-22 09:53:42 UTC
(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.

Comment 16 Marcela Mašláňová 2013-11-28 14:40:06 UTC
Created attachment 830271 [details]
split _scl_prefix macro

Comment 17 Marcela Mašláňová 2013-11-28 14:42:20 UTC
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.

Comment 18 Jan Zeleny 2013-11-28 19:01:06 UTC
The patch is not necessary, there already was a patch upstream that I reverted. I'll probably just revert/extend the reversion.

Comment 19 Vít Ondruch 2014-01-07 09:34:30 UTC
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.

Comment 20 Fedora Update System 2014-01-10 14:04:43 UTC
scl-utils-20140108-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/scl-utils-20140108-1.fc19

Comment 21 Fedora Update System 2014-01-10 14:05:10 UTC
scl-utils-20140108-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-20140108-1.fc20

Comment 22 Fedora Update System 2014-01-11 08:30:41 UTC
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).

Comment 23 Fedora Update System 2014-01-27 12:08:02 UTC
scl-utils-20140127-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/scl-utils-20140127-1.fc19

Comment 24 Fedora Update System 2014-01-27 12:08:34 UTC
scl-utils-20140127-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/scl-utils-20140127-1.fc20

Comment 25 Fedora Update System 2014-03-01 14:05:50 UTC
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.

Comment 26 Fedora Update System 2014-03-01 14:13:47 UTC
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.


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