[Bug 797238] New: erlang-rabbitmq-client installs to system-wide location, potentially breaking rabbitmq-server
https://bugzilla.novell.com/show_bug.cgi?id=797238 https://bugzilla.novell.com/show_bug.cgi?id=797238#c0 Summary: erlang-rabbitmq-client installs to system-wide location, potentially breaking rabbitmq-server Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 0 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: simon@rabbitmq.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/10.04 Chromium/18.0.1025.168 Chrome/18.0.1025.168 Safari/535.19 I hope I'm filing this in the right place. Apologies if not. The suse-specific RPM erlang-rabbitmq-client installs amqp_client-<version>.ez and rabbitmq_common-<version>.ez to %{_libdir}/erlang/lib/ - i.e. /usr/lib/erlang/lib/. This makes them available to all Erlang programs installed on the system. (Source: https://build.opensuse.org/package/view_file?expand=1&file=rabbitmq-server.spec&package=rabbitmq-server&project=openSUSE%3AFactory) The trouble is, this can conflict with the version of amqp_client used internally by rabbitmq-server. If the versions of rabbitmq-server and erlang-rabbitmq-client are the same, you're good. If not, various mysterious errors will occur in rabbitmq-server. (For an example of someone running into this, see the thread starting at http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2013-January/024808.htm...) AFAICS this affects all (well, both) versions of erlang-rabbitmq-client. Reproducible: Always Steps to Reproduce: 1. Install erlang-rabbitmq-client RPM of one version e.g. 2.8.7 2. Install rabbitmq-server RPM of another version e.g. 3.0.1 (see http://www.rabbitmq.com/install-rpm.html) 3. Try to use any function in rabbitmq-server that uses amqp_client internally (probably the simplest thing is to declare a queue using the management plugin, but you could also use the STOMP or MQTT protocols, use federation or the shovel). Actual Results: Such functions fail with errors including: {case_clause, {amqp_params_direct, ...}} Expected Results: Such functions succeed. Possible solutions: 1) Don't install amqp_client and rabbit_common to /usr/lib/erlang/lib/; they are not part of Erlang / OTP. If that is not possible: 2) Mark the erlang-rabbitmq-client RPM as conflicting with all versions of rabbitmq-server other than the one it was built from. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c1
--- Comment #1 from Matwey Kornilov
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c2
--- Comment #2 from Simon MacMullen
AFAIK, lots of third-party installs into %{_libdir}/erlang/lib. It is also part of Fedora's packaging convention, I don't see any problem here. Please, correct me if I am wrong.
It may be widespread, but it's still wrong IMO. The problem is that anything installed into %{_libdir}/erlang/lib *will* override any other version of the same code anyone tries to use. There is no escape. I'm not a packaging expert, but I'm sure that e.g. Java / Python packaging doesn't work this way on any distro. You don't try to make installed libraries look like part of the base system.
Conflicts: tag (AFAIK) doesn't allow inequalities.
Ah.
My suggestion is to extract rabbit_common into separate package and make rabbitmq-server depend on rabbit_common and amqp_client (and use their beam-code). This would resolve such conflicts in future.
Sort of. As long as the rabbitmq-server RPM specifies the exact version of rabbit_common it depends on. But you still have problems if (for example) someone installs the rabbit_common RPM and then installs a different version of RabbitMQ from some other mechanism than the SUSE RPM (our RPMs, or a binary tarball, or build from source). It'll still break, because you forced that version of rabbit_common on every user of Erlang on the system.
Because there are two use-cases. 1) Running RabbitMQ server instance on the server. 2) Running some Erlang application which is AMQP-client (and hence depends on amqp_client). In the latter case user don't want to install RabbitMQ itself.
Oh, I agree 100% :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c3
Matwey Kornilov
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c
Jiaying ren
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c
Christoph Thiel
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c
Milisav Radmanic
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c4
Ralf Haferkamp
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c5
--- Comment #5 from Matwey Kornilov
It may be widespread, but it's still wrong IMO.
I'm not a packaging expert, but I'm sure that e.g. Java / Python packaging doesn't work this way on any distro.
It would be great to have site-packages and vendor-packages places for erlang, but upstream developers gives us no choice. Moreover, we install no-arch data into libarch place (and this is a problem, because we have to compile the same code for i586, x64, armv6, armv7, etc.), because upstream developers gives us no choice. What could be done right now is to remove doubling code from SUSE rabbitmq package, making it depend on erlang-amqp_client and erlang-rabbitmq_common packages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=797238
https://bugzilla.novell.com/show_bug.cgi?id=797238#c6
--- Comment #6 from Sascha Peilicke
As for me, I only partially agree with this statements:
It may be widespread, but it's still wrong IMO.
I'm not a packaging expert, but I'm sure that e.g. Java / Python packaging doesn't work this way on any distro.
It would be great to have site-packages and vendor-packages places for erlang, but upstream developers gives us no choice. Moreover, we install no-arch data into libarch place (and this is a problem, because we have to compile the same code for i586, x64, armv6, armv7, etc.), because upstream developers gives us no choice.
What could be done right now is to remove doubling code from SUSE rabbitmq package, making it depend on erlang-amqp_client and erlang-rabbitmq_common packages.
I sort of agree, without "considerable effort", avoiding the conflicts seems to be the easiest way out. The only thing we have to make sure is that "doubling code" is actually "identical code". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com