Bug 784693 - Too many dependencies from Erlang
Summary: Too many dependencies from Erlang
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: erlang
Version: rawhide
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL: https://fedoraproject.org/wiki/Change...
Whiteboard:
: 680633 810586 912050 1009238 (view as bug list)
Depends On: 1095715 1095717 1095718 1095721 1095727 1095699 1095702 1095703 1095705 1095708 1095709 1095710 1095712
Blocks: 1086146 1161922
TreeView+ depends on / blocked
 
Reported: 2012-01-25 19:59 UTC by Alexander Todorov
Modified: 2018-04-11 10:14 UTC (History)
18 users (show)

Fixed In Version: erlang-R16B-03.9.fc20
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1161922 (view as bug list)
Environment:
Last Closed: 2014-11-18 12:34:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexander Todorov 2012-01-25 19:59:46 UTC
Description of problem:

rabbitmq-server has Require: erlang >= R12B-3 which pulls in every possible erlang package and it's dependencies including: gtk2, atk, tk, SDL and so on. 


When using Amazon Linux AMI in Amazon EC2 it points by default to EPEL 6 repository. The side effect is that trying to install rabbitmq-server fails with lots of missing dependencies. I tried to rebuild the packages myself but there are way too many packages needed in order to build all necessary dependencies.


I doubt that wxGTK and friends are all necessary for Rabbitmq. Can you please fix the EPEL package so it lists only necessary dependencies and not the whole world. 

The Amazon forums thread is here:
https://forums.aws.amazon.com/message.jspa?messageID=282648


Version-Release number of selected component (if applicable):
rabbitmq-server-2.6.1-1.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. yum install rabbitmq-server on Amazon Linux AMI

Comment 1 Peter Lemenkov 2012-01-25 20:42:26 UTC
I really really wish it could be fixed just removing several dependencies. Unfortunately it isn't that easy.

The main problem is that although this X11 stuff indeed does not required for RabbitMQ to run it does required for debugging and on-the-fly analysis. From someone's point of view if (s)he fails to reproduce some debugging recipes from internet (for example, starting appmon:start() or debugger:start()) then it's time to blame packager for broken Erlang distribution and honestly I think it would be true.

So from the one hand - several X11 libraries and broken dependency chain in broken variant of RHEL but fully functional Erlang distribution, from the other hand - Erlang with truncated essential functionality but happy casual RabbitMQ/Ejabberd/CouchDB/Mochiweb users.

Honestly I really feel for you and will try to cut off a dependency chain but I also don't want to break something. I plan to do something a bit more complicated rather than just removing some dependencies - for example some kind of "soft" dependencies using empty metapackages like erlang-debugger-x11 or erlang-appmon-x11. Without them every attempt to run some GUI tools from the console should end up with informative message about packages which must be installed manually.

So bottom line is - I'd like this ticket to stay open for a while (until I or someone else proposes something acceptable). But right now it looks like a bug with Amazon infrastructure.

Comment 2 Alexander Todorov 2012-01-26 09:42:30 UTC
Hi Peter,
thanks for the quick response. 

It's OK with me to split the dependencies in two and be able to handle console users and GUI too. I hope it's not that hard to implement.

Comment 3 Alexander Todorov 2012-01-26 13:31:51 UTC
FYI I asked upstream about dependencies. This may be helpful:
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-January/017687.html

How about something like:
rabbitmq-server
rabbitmq-server-ssl
rabbitmq-server-hipe
... etc 


Is it easy to break it down like this?

Comment 4 Peter Lemenkov 2012-04-08 16:43:40 UTC
*** Bug 810586 has been marked as a duplicate of this bug. ***

Comment 5 Peter Lemenkov 2012-04-08 16:45:55 UTC
Changing component to erlang and reassigning to myself.

Comment 6 Pavol Rusnak 2012-08-15 12:19:58 UTC
Same issue while installing ejabberd. I guess ejabberd should require just particular erlang modules, not the whole erlang metapackage.

Comment 7 Peter Lemenkov 2013-07-23 13:20:52 UTC
*** Bug 912050 has been marked as a duplicate of this bug. ***

Comment 8 Peter Lemenkov 2013-07-23 13:21:46 UTC
*** Bug 680633 has been marked as a duplicate of this bug. ***

Comment 9 Adam Williamson 2013-09-18 04:11:48 UTC
*** Bug 1009238 has been marked as a duplicate of this bug. ***

Comment 10 Adam Williamson 2013-09-18 04:13:21 UTC
Yeah, I just hit this trying to install ejabberd too.

Seriously, I'm not installing *two* graphical toolkits on my headless server just to get a jabber server going.

Debian has an 'erlang-nox' metapackage which depends on all of erlang except the bits that require X:

http://packages.debian.org/sid/erlang-nox

and Debian's ejabberd package requires it. Perhaps you could do that?

Comment 11 Peter Lemenkov 2014-04-02 16:13:41 UTC
*** Bug 1083637 has been marked as a duplicate of this bug. ***

Comment 12 Peter Lemenkov 2014-04-02 16:15:23 UTC
Heads up. Due to numerous requests it was decided to fix this issue (enable "headless" Erlang) as a Fedora 21 feature. I plan to backport it to the rest of Erlang branches (including not yet released EL7).

Comment 13 Peter Lemenkov 2014-04-02 16:17:57 UTC
See https://fedoraproject.org/wiki/Changes/BetterErlangSupport

Comment 14 Lon Hohberger 2014-04-02 17:59:31 UTC
Nice write-up, Peter!

Would it make sense to note your idea where applications which can use the GUI (but don't need it) throw an error when someone attempts to start them in GUI mode instead of having GUI libraries as hard install requirements?

Comment 15 Lon Hohberger 2014-04-04 18:10:19 UTC
Also, would it make sense to make erlang (source rpm) buildable without wx* in the first place?

Comment 16 Fedora Update System 2014-11-09 15:00:08 UTC
erlang-17.3.4-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/erlang-17.3.4-1.fc21

Comment 17 Peter Lemenkov 2014-11-09 15:06:54 UTC
Heads up!

I believe I fixed *almost* all most annoying use cases where installing Erlang-application pulls a half of GUI stack. Unfortunately this is available in F-21 and Rawhide for now. I'm backporting all the necessary changes to EL7 (see bug #1161922) right now.

Unfortunately no luck for poor F-19, F-20 users. Sorry but you'd better to upgrade to F-21. Likewise, no luck for EL6, EL5 users for now.

Still some issues remains - installing any of these will pull the libX11 chain again:

* erlang-debugger
* erlang-dialyzer
* erlang-et
* erlang-observer
* erlang-reltool

So even if you want remote debugging with erlang-observer it will pull libX11 syack again. I'm thinking on how to handle it properly.

However if you just want to use RabbitMQ / CouchDB you will definitely notice the improvements.

Comment 18 Fedora Update System 2014-11-10 06:45:50 UTC
Package erlang-17.3.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing erlang-17.3.4-1.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-14648/erlang-17.3.4-1.fc21
then log in and leave karma (feedback).

Comment 19 Fedora Update System 2014-11-18 09:06:24 UTC
erlang-R16B-03.9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/erlang-R16B-03.9.fc20

Comment 20 Fedora Update System 2014-11-18 12:34:17 UTC
erlang-17.3.4-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2014-12-01 18:56:58 UTC
erlang-R16B-03.9.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.