Bug 1476614

Summary: RFE: Modify the Erlang VM to search in /usr/share/erlang/lib for noarch libs
Product: [Fedora] Fedora Reporter: Randy Barlow <randy>
Component: erlangAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: erlang, jeckersb, lemenkov, plemenko, rhbugs, s
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: erlang-19.3.6.2-2.fc27 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-11 14:38:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1434311    
Attachments:
Description Flags
noarch_libs.patch none

Description Randy Barlow 2017-07-30 18:51:43 UTC
Created attachment 1306684 [details]
noarch_libs.patch

Description of problem:
As part of a change for Fedora 27, I have written a patch for the erlang spec file that will modify the Erlang VM to also search in /usr/share/erlang/lib for noarch libs. I am attaching a patch I wrote that uses sed in the spec file to append this new path just before the archful libs in the search path.

I have tested this patch with ejabberd by moving one of its dependencies (p1_utils) into the new /usr/share/erlang/lib. Without this patch ejabberd fails to start, but with the patch it starts up successfully.

Once we have this patch applied, we just need to modify the RPM macros to use the new path for noarch packages and we'll have the change completed.

Comment 1 Randy Barlow 2017-07-30 19:15:30 UTC
I tried to build erlang-cache_tab with this patch applied on my system, and it looks like rebar does not find p1_utils:

+ /usr/bin/rebar eunit skip_deps=true -vv                                                                             
DEBUG: Evaluating config script "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/rebar.config.script"                    
DEBUG: Consult config file "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/rebar.config"                                
DEBUG: Rebar location: "/usr/bin/rebar"                                                                               
DEBUG: Consult config file "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/src/cache_tab.app.src"                        
DEBUG: is_app_available, looking for App p1_utils with Path "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/deps/p1_utils"                                                                                                                      
DEBUG: Directory expected to be an app dir, but it doesn't exist (yet?):                                               
/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/deps/p1_utils                                                            
DEBUG: Available deps: []                                  
DEBUG: Missing deps  : [{dep,bad_name,p1_utils,".*",       
                             {git,"https://github.com/processone/p1_utils",                                           
                                  {tag,"1.0.9"}},                                                                     
                             false}]

Does rebar not use Erlang's code_server.erl to find its libs? If not, I think we might need to either patch rebar, or patch the macros to add the new path to the search path for rebar.

What do you think?

Comment 2 Randy Barlow 2017-07-30 19:41:40 UTC
https://github.com/lemenkov/erlang-rpm-macros/pull/4/ will modify the RPM macros to build into the new location. Now we just need to figure out how to get Rebar to look in the right place for dependencies.

Comment 3 Peter Lemenkov 2017-08-01 14:37:50 UTC
(In reply to Randy Barlow from comment #1)
> I tried to build erlang-cache_tab with this patch applied on my system, and
> it looks like rebar does not find p1_utils:
> 
> + /usr/bin/rebar eunit skip_deps=true -vv                                   
> 
> DEBUG: Evaluating config script
> "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/rebar.config.script"          
> 
> DEBUG: Consult config file
> "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/rebar.config"                 
> 
> DEBUG: Rebar location: "/usr/bin/rebar"                                     
> 
> DEBUG: Consult config file
> "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/src/cache_tab.app.src"        
> 
> DEBUG: is_app_available, looking for App p1_utils with Path
> "/home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/deps/p1_utils"                
> 
> DEBUG: Directory expected to be an app dir, but it doesn't exist (yet?):    
> 
> /home/rbarlow/rpmbuild/BUILD/cache_tab-1.0.9/deps/p1_utils                  
> 
> DEBUG: Available deps: []                                  
> DEBUG: Missing deps  : [{dep,bad_name,p1_utils,".*",       
>                              {git,"https://github.com/processone/p1_utils", 
> 
>                                   {tag,"1.0.9"}},                           
> 
>                              false}]
> 
> Does rebar not use Erlang's code_server.erl to find its libs? If not, I
> think we might need to either patch rebar, or patch the macros to add the
> new path to the search path for rebar.
> 
> What do you think?

I believe rebar redefines paths in some different way (to include ./deps/*/ebin and some other paths) so I think it's not a blocker at this point.

What I'd consider a successful Feature completion is running some code from /usr/share without providing any extra command line switches.

Comment 4 Peter Lemenkov 2017-08-11 14:38:11 UTC
Initial implementation in erlang-19.3.6.2-2.fc27. Let's test it!

Comment 5 Randy Barlow 2017-08-11 19:20:51 UTC
Fantastic, thanks Peter!

Just to give you a heads up, it was decided in today's FESCo meeting that I didn't get all of the changes needed for the Erlang noarch change done in time (since Rebar still doesn't work). Thus, they have decided to delay the change until Fedora 28.

That's OK though, we can just make the rebar and rpm macro changes on Rawhide after Fedora 27 branches. This change shouldn't harm anything on Fedora 27 since it won't fail if there aren't libs in /usr/share.