Bug 999054
| Summary: | deps are satisifed locally even if source is specified | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Maciek Borzecki <maciek.borzecki> |
| Component: | erlang-rebar | Assignee: | Peter Lemenkov <lemenkov> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | lemenkov |
| Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | erlang-rebar-2.6.4-2.fc25 erlang-rebar-2.6.4-2.fc24 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-09-06 18:19:55 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: | |||
(In reply to Maciek Borzecki from comment #0) > Description of problem: > > Having the following rebar.config, rebar get-deps will not download lager > source code from github but will satisfy with locally installed erlang-lager > package. That's intentional. Fedora policy encourages using system-wide components and code reuse so I patched rebar to pick up stuff from %{_libdir}/erlang/lib first (if version matches to regexp expression in rebar.config). If you want to restore original behaviour then either remove system-wide copies with yum, or use your own copy of rebar. But I really hope you'll reconsider and will rely on system-wide packages. After thinking a bit more about this issue I believe we can do even better - how about the following: * rebar from Fedora acts as upstream one in case of get-deps, but * rebar from Fedora uses system-wide copies if possible in case of compile / eunit /ct / edoc So one can override system-wide copies if necessary, and rebar will still work according to Fedora policies in case of automatic building in Koji. Maciek, what do you think about that? (In reply to Peter Lemenkov from comment #2) > After thinking a bit more about this issue I believe we can do even better - > how about the following: > > * rebar from Fedora acts as upstream one in case of get-deps, but > * rebar from Fedora uses system-wide copies if possible in case of compile / > eunit /ct / edoc > > So one can override system-wide copies if necessary, and rebar will still > work according to Fedora policies in case of automatic building in Koji. > Maciek, what do you think about that? I'm not sure if I understand how rebar does not conform to Fedora's policy of using local deps if avaialble. The current rebar upstream implements this behaviour out of the box. Unless for given dep, source location is explicitly listed, rebar check only locally available packages. Now, if I explicitly set the source to use git, I really mean it. Failure to pull the source from git breaks the principle of least surprise. For clarity, this rebar.config will fail if local dependencies are not met (like missing erlang-lager): {deps, [ {riakc, "^1.3.*"}, {lager, "^1.2.*"} ]}. Now, imagine I have some changes I need to apply to lager, or use 1.2 from a patched branch, the following config will not provide a desirable result: {deps, [ {riakc, "^1.3.*"}, {lager, "^1.2*", {git, "git://my-git-site.com/lager.git", {branch, "1.2-patched"}}}, ]}. The behaviour you suggest is totally fine for a Riak or RMQ system, but it unfortunately breaks if you do actual Erlang development. Given how disorganized developing for Erlang with 3rd party packages is, it's impossible to package all possible deps in all possible versions. This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. erlang-rebar-2.6.4-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-973dc30ca6 erlang-rebar-2.6.4-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ba070a6284 erlang-rebar-2.6.4-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-ba070a6284 erlang-rebar-2.6.4-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-973dc30ca6 erlang-rebar-2.6.4-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report. erlang-rebar-2.6.4-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: Having the following rebar.config, rebar get-deps will not download lager source code from github but will satisfy with locally installed erlang-lager package. {erl_opts, [{parse_transform, lager_transform}, debug_info]}. {deps, [ {lager, ".*", {git, "git://github.com/basho/lager.git", "master"}} ]}. Version-Release number of selected component (if applicable): erlang-rebar-2.1.0-0.4.fc19.x86_64 How reproducible: always Steps to Reproduce: 1. have rebar.config with sources listed for deps 2. have at least one dep met from /usr/lib/erlang/lib 3. run rebar get-deps Actual results: dependencies are satisfied from /usr/lib/erlang/lib Expected results: source to be downloaded locally to project/deps dir Additional info: Fedora patch rebar-0006-Check-system-wide-libdir-in-case-of-source-based-dep.patch breaks current upstream behavior. Upstream will download dep source code if source location is defined in rebar.config.