Your message dated Tue, 2 Aug 2016 12:46:38 +0200
with message-id
<CAK0OdpzmYrGTJsh=b4upgrztgpurzg_gzadvvorode-j8ol...@mail.gmail.com>
and subject line Re: erlang-cowboy installs to /usr/lib/erlang/lib
has caused the Debian Bug report #748343,
regarding erlang-cowboy installs to /usr/lib/erlang/lib
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
748343: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748343
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: erlang-cowboy
Version: 0.8.6+dfsg1-1
X-Debbugs-CC: [email protected]
The package "erlang-cowboy" installs a specific version of Cowboy
(currently 0.8.6) into the system-wide OTP directory.
This means that any Erlang application gets that version of Cowboy in
preference to any other it might have installed, probably breaking it.
RabbitMQ's web stomp plugin is an example of such an application.
This is a bad idea for any Erlang library, and it's a particularly bad
idea for Cowboy as it has a rather fast-moving API.
Cheers, Simon
--
Simon MacMullen
RabbitMQ, Pivotal
--- End Message ---
--- Begin Message ---
Control: notfound -1 0.8.6+dfsg1-1
Dear Simon,
2016-01-24 22:11 GMT+01:00 Balint Reczey <[email protected]>:
> Hi Simon,
>
> On Wed, 25 Jun 2014 11:55:33 +0100 Simon MacMullen <[email protected]>
> wrote:
>> On 25/06/14 10:21, Sergei Golovan wrote:
>> > I think that installing erlang-cowboy into the system-wide Erlang
>> > directory is fine.
>> > If an application needs cowboy then it can either
>> >
>> > 1) ensure it works wit a system-wide version and depend on erlang-cowboy,
>> > or
>>
>> This would be tremendously painful since the API of cowboy undergoes
>> frequent incompatible changes.
> This is true for many C libraries as well. The process of upgrading
> libraries involves coordination with reverse dependencies and if any
> Debian package depended on on erlang-cowboy, their maintainers had been
> notified for API bumps.
>
> $ apt-cache rdepends erlang-cowboy
> erlang-cowboy
> Reverse Depends:
> erlang-cowboy-examples
>
>>
>> > 2) include its own version and make sure that it's the one which is used
>> > (add -pa option to erl or otherwise).
>>
>> We load the code dynamically, so -pa won't work. We may be able to
>> change our code loading strategy though.
> There is also ErlSvc, which may or may not help in maintaining the
> version of Erlang applications used:
> https://packages.qa.debian.org/e/erlsvc.html
>
>>
>> > I'd prefer that this local cowboy wasn't
>> > easily accessible by other Erlang applications (god knows which local
>> > changes
>> > it has).
>>
>> Believe me, we do not add it to a path that any other application could
>> pick up.
>>
>> > Anyway, placing applications from regular Debian packages into
>> > /usr/lib/erlang
>> > shouldn't be considered a bug.
>>
>> Well, if that's the decision then fair enough. For most other languages
>> though it seems to be policy that the language's standard library goes
>> in a different place from any other random packages; I assumed that was
>> the default.
> I will happily adapt to any scheme for Debian's Erlang packages, but I
> think erlang-cowboy is packaged properly according to the current scheme.
> Note that erlang-cowboy does not change in stable and you can always
> stick to one particular package version on your production system if
> you don't want changes in testing/unstable:
Closing the bug since the package aligns with Debian packaging practices.
Now erlang-cowboy has one reverse dependency, averell thus future API changes
will be done in collaboration with averell's maintainers.
If you would like to keep web stomp in sync with cowboy please have web stomp
packaged in Debian thus we can track it during API changes.
Cheers,
Balint
--- End Message ---
