Bug 985336 - split prefix macro in two parts
Summary: split prefix macro in two parts
Keywords:
Status: CLOSED DUPLICATE of bug 985233
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: scl-utils
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Jan Zeleny
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 985233
TreeView+ depends on / blocked
 
Reported: 2013-07-17 10:11 UTC by Marcela Mašláňová
Modified: 2013-11-14 14:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 985233
Environment:
Last Closed: 2013-11-14 14:39:18 UTC


Attachments (Terms of Use)

Comment 3 Marcela Mašláňová 2013-10-29 12:40:09 UTC
We'd like to define vendor in separate macro. Current definition of prefix =  /opt/rh is not very nice.

We also would like to see adding another directory into /opt, so more vendors could install same collection, for example
/opt/vendor/user/ruby193
/opt/vendor/user2/ruby193

Comment 4 Jan Zeleny 2013-10-30 11:39:00 UTC
(In reply to Marcela Mašláňová from comment #3)
> We'd like to define vendor in separate macro. Current definition of prefix =
> /opt/rh is not very nice.

I still don't get what are you hoping to achieve with this. Right now to redefine the scl prefix, you just need to redefine one macro: %_scl_prefix. With this change, you will *still* need to redefine one macro, it will just be called differently: %_scl_vendor. Please specify what exactly are you hoping to achieve here that is not achievable already, otherwise I will close the bug again!

> We also would like to see adding another directory into /opt, so more
> vendors could install same collection, for example
> /opt/vendor/user/ruby193
> /opt/vendor/user2/ruby193

This is completely different request and not exactly a simple one, as it breaks a substantial amount of both backward and forward compatibility.

Comment 5 Bohuslav "Slavek" Kabrda 2013-10-30 12:12:47 UTC
(In reply to Jan Zeleny from comment #4)
> (In reply to Marcela Mašláňová from comment #3)
> > We'd like to define vendor in separate macro. Current definition of prefix =
> > /opt/rh is not very nice.
> 
> I still don't get what are you hoping to achieve with this. Right now to
> redefine the scl prefix, you just need to redefine one macro: %_scl_prefix.
> With this change, you will *still* need to redefine one macro, it will just
> be called differently: %_scl_vendor. Please specify what exactly are you
> hoping to achieve here that is not achievable already, otherwise I will
> close the bug again!
> 

The thing is, that we don't want to redefine the "/opt" part everywhere, we just want to redefine the vendor. By having only %_scl_prefix, you effectively have to define the path and the vendor in one place together. E.g. you can't for example have buildroot that defines %scl_path macro and an SCL metapackage that defines it's own vendor, while not having to care what the path is.

> > We also would like to see adding another directory into /opt, so more
> > vendors could install same collection, for example
> > /opt/vendor/user/ruby193
> > /opt/vendor/user2/ruby193
> 
> This is completely different request and not exactly a simple one, as it
> breaks a substantial amount of both backward and forward compatibility.

I guess this would be better solved by just using user_ruby193 for collection name.

Comment 6 Miroslav Suchý 2013-10-30 12:30:17 UTC
I thought that the reason was little different:

We want to allow user to build their own collection (likely in Copr and scl.org) and since two users can very likely choose the same name (eg. ruby193) we would need to difference by vendor. e.g:
 /opt/msuchy/ruby193
 /opt/jzeleny/ruby193

But if we want to take it seriously we have to register all path under /opt. And this is impossible. Therefore we need something like:

 /opt/scl.org/msuchy/ruby193
 /opt/scl.org/jzeleny/ruby193

Note: this is not goal of this BZ, but spliting the prefix into two parts seems to be required step on this path.

Comment 7 Jan Zeleny 2013-10-30 12:42:44 UTC
(In reply to Bohuslav "Slavek" Kabrda from comment #5)
> (In reply to Jan Zeleny from comment #4)
> > (In reply to Marcela Mašláňová from comment #3)
> > > We'd like to define vendor in separate macro. Current definition of prefix =
> > > /opt/rh is not very nice.
> > 
> > I still don't get what are you hoping to achieve with this. Right now to
> > redefine the scl prefix, you just need to redefine one macro: %_scl_prefix.
> > With this change, you will *still* need to redefine one macro, it will just
> > be called differently: %_scl_vendor. Please specify what exactly are you
> > hoping to achieve here that is not achievable already, otherwise I will
> > close the bug again!
> > 
> 
> The thing is, that we don't want to redefine the "/opt" part everywhere, we
> just want to redefine the vendor. By having only %_scl_prefix, you
> effectively have to define the path and the vendor in one place together.
> E.g. you can't for example have buildroot that defines %scl_path macro and
> an SCL metapackage that defines it's own vendor, while not having to care
> what the path is.

The last time I was on call with FPC, I got the opposite impression, they want to be able to redefine both the /opt and vendor part. Anyway, I think I understand your use case better thanks to the example.

> > > We also would like to see adding another directory into /opt, so more
> > > vendors could install same collection, for example
> > > /opt/vendor/user/ruby193
> > > /opt/vendor/user2/ruby193
> > 
> > This is completely different request and not exactly a simple one, as it
> > breaks a substantial amount of both backward and forward compatibility.
> 
> I guess this would be better solved by just using user_ruby193 for
> collection name.

Agreed. Not exactly pretty but if we want to avoid rebasing scl-utils in all existing channels or risking scl crashes, I don't think we have a choice.

Comment 8 Jan Zeleny 2013-11-14 14:39:18 UTC

*** This bug has been marked as a duplicate of bug 985233 ***


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