Bug 1476614 - RFE: Modify the Erlang VM to search in /usr/share/erlang/lib for noarch libs
RFE: Modify the Erlang VM to search in /usr/share/erlang/lib for noarch libs
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: erlang (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Peter Lemenkov
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1434311
  Show dependency treegraph
 
Reported: 2017-07-30 14:51 EDT by Randy Barlow
Modified: 2017-08-11 15:20 EDT (History)
6 users (show)

See Also:
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 10:38:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
noarch_libs.patch (2.07 KB, application/mbox)
2017-07-30 14:51 EDT, Randy Barlow
no flags Details

  None (edit)
Description Randy Barlow 2017-07-30 14:51:43 EDT
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 15:15:30 EDT
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 15:41:40 EDT
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 10:37:50 EDT
(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 10:38:11 EDT
Initial implementation in erlang-19.3.6.2-2.fc27. Let's test it!
Comment 5 Randy Barlow 2017-08-11 15:20:51 EDT
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.

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