[erlang-questions] debian & ubuntu R14B

[Max Lapshin]

Ubuntu package is frozen at R13B04 and Debian on R13. Also, it would
be very cool to see builds for 9.10, 10.04 and lenny.
Maybe maintainer is here and he just needs help with building it?

Or the easiest way for me is to make debian folder for builds for
exact platforms, which must be stored near erlyvideo?

________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questio...@erlang.org

[Vincenzo Di Somma]

We discussed a bit about packaging Erlang at the Erlang Factory in
London this year.
One very interesting suggestion was to improve the separation of the
runtime environment from the development environment.

vds

[Max Lapshin]

On Thu, Oct 28, 2010 at 6:05 PM, Vincenzo Di Somma
<vincenzo...@canonical.com> wrote:
> We discussed a bit about packaging Erlang at the Erlang Factory in
> London this year.
> One very interesting suggestion was to improve the separation of the
> runtime environment from the development environment.
>

Maybe it is a good idea to split into erlang and erlang-dev, maybe
not, but when there are no fresh packages for months and it still
requires some knowledge hidden inside one person to build a package,
everything ends in ./configure && make && make install on production
server.

I tried to build R14B for squeeze, but failed: too complex build setup
required. If situation doesn't change, I will have to refuse from
building debian package because of no erlang in debian or ubuntu.

[Anthony Molinaro]

It's not debian, but for the last few versions of erlang, I've been updating
the EPEL spec file and patches. The nice thing is that several patches
became unnecessary between R12 and R13, most of the rest disappeared with
R14 (the one remaining patch just disables the formating of man pages).
So right now I have a pretty vanilla setup, very simple .spec and a single
patch (you can build the whole thing with rpmbuild -ba erlang.spec), I
attached the spec and patch (both derived from those included in the EPEL
SRPM of R12).

It may be that its easier to package when you have a single package for
the whole thing?

Anyway, maybe it will help in packaging for debian/ubuntu, to see an
rpm example?

-Anthony

--
------------------------------------------------------------------------
Anthony Molinaro <anth...@alumni.caltech.edu>

[Alessandro Sivieri]

We could try to backport packages from the next Ubuntu release, assuming
that it will have the R14B release; the first alpha of 11.04 should come out
in a few days, if I remember correctly...

--
Sivieri Alessandro
alessandr...@gmail.com
http://www.chimera-bellerofonte.eu/
http://www.poul.org/

[Vincenzo Di Somma]

The next Ubuntu release, 11.04, will be out on April 2011 and unless
something changes it will probably ship the same version that has been
shipped so far.
I haven't worked on the .deb packages myself but I've heard it's a quite
complicated by the big number of dependencies the erlang tarball has.
I'm under the impression that splitting the runtime and the development
environment will make the packaging and the maintenance of the packages
a lot easier.
Thanks,

vds

[Vincenzo Di Somma]

On Thu, 2010-10-28 at 11:48 -0700, Anthony Molinaro wrote:
> It's not debian, but for the last few versions of erlang, I've been updating
> the EPEL spec file and patches. The nice thing is that several patches
> became unnecessary between R12 and R13, most of the rest disappeared with
> R14 (the one remaining patch just disables the formating of man pages).
> So right now I have a pretty vanilla setup, very simple .spec and a single
> patch (you can build the whole thing with rpmbuild -ba erlang.spec), I
> attached the spec and patch (both derived from those included in the EPEL
> SRPM of R12).
>
> It may be that its easier to package when you have a single package for
> the whole thing?

I think it will make things much worse.

> Anyway, maybe it will help in packaging for debian/ubuntu, to see an
> rpm example?

If it's one big huge rmp, nope it's not going to help. :)
Thanks,

vds

[Max Lapshin]

Frankly speaking, I'm going to create monolitic packages (only one
erlang package) for two versions of debian and ubuntu. Just for those,
who is not going to wait two years for official build.

[Anthony Molinaro]

I think monolithic is the way to go. OTP is released all as one thing so I don't see how splitting it would help you over time, maintenance would be a pain. With a monolithic package its very minimal to update, R14B took me about an hour to package and push to our yum repo.

-Anthony

[Max Lapshin]

On Sun, Oct 31, 2010 at 1:07 AM, Anthony Molinaro
<anth...@alumni.caltech.edu> wrote:
> I think monolithic is the way to go. OTP is released all as one thing so I don't see how splitting it would help you over time, maintenance would be a pain.  With a monolithic package its very minimal to update, R14B took me about an hour to package and push to our yum repo.
>

I don't understand what for to split erlang into many several
subpackages. Who in the hell will ever install only erlang-corba
without, for example, erlang-megaco?

[Vincenzo Di Somma]

On Sun, 2010-10-31 at 01:17 +0400, Max Lapshin wrote:
> On Sun, Oct 31, 2010 at 1:07 AM, Anthony Molinaro
> <anth...@alumni.caltech.edu> wrote:
> > I think monolithic is the way to go. OTP is released all as one thing so I don't see how splitting it would help you over time, maintenance would be a pain. With a monolithic package its very minimal to update, R14B took me about an hour to package and push to our yum repo.
> >
>
> I don't understand what for to split erlang into many several
> subpackages. Who in the hell will ever install only erlang-corba
> without, for example, erlang-megaco?

It's actually the other way around, why would I have erlang-corba on my
machine if I only run say CouchDB?
Thanks,
vds

[Max Lapshin]

On Sun, Oct 31, 2010 at 1:23 AM, Vincenzo Di Somma
<vincenzo...@canonical.com> wrote:
>
> It's actually the other way around, why would I have erlang-corba on my
> machine if I only run say CouchDB?
> Thanks,
>                        vds

I'm not speaking about "what can be in ideal world". I'm speaking
about: have you ever deselected erlang-corba, when running only
couchdb?

[Vincenzo Di Somma]

On Sun, 2010-10-31 at 01:24 +0400, Max Lapshin wrote:
> On Sun, Oct 31, 2010 at 1:23 AM, Vincenzo Di Somma
> <vincenzo...@canonical.com> wrote:
> >
> > It's actually the other way around, why would I have erlang-corba on my
> > machine if I only run say CouchDB?
> > Thanks,
> > vds
>
> I'm not speaking about "what can be in ideal world". I'm speaking
> about: have you ever deselected erlang-corba, when running only
> couchdb?

Sorry I am speaking of an ideal world, because I don't see it very far.
In Ubuntu, at the moment we have around 50 packages out of one single
Erlang tarball. If we can only move the effort a bit the from creating
distribution packages to releasing a tarball that can be packaged more
easily, it will pay a lot in the long term.
Thanks,
vds

[Elliot Murphy]

On Oct 30, 2010, at 5:24 PM, Max Lapshin <max.l...@gmail.com> wrote:

> On Sun, Oct 31, 2010 at 1:23 AM, Vincenzo Di Somma
> <vincenzo...@canonical.com> wrote:
>>
>> It's actually the other way around, why would I have erlang-corba on my
>> machine if I only run say CouchDB?
>> Thanks,
>> vds
>
> I'm not speaking about "what can be in ideal world". I'm speaking
> about: have you ever deselected erlang-corba, when running only
> couchdb?

Uh, yes. This is not ideal world, this is a real problem that affects end users. Ubuntu includes CouchDB on the livecd, and absolutely does not want all of OTP dragged in as a dependency. Every release there is pressure to remove Erlang and CouchDB to free up more space on the CD. Every few K helps - I want these technologies available in more environments such as mobile and tablet, where space is even more important.

-elliot

[Alessandro Sivieri]

This is something like a similar discussion happened in the ruby mailing
list: Debian (and consequently Ubuntu) has the package separation as a
general philosophy, so that each user can install only what it needs. For
example, I installed Erlang in a minimal Debian installation, and I avoided
the all metapackage and installed only the core and some other packages, so
I avoided installing X packages (which are needed by some erlang-*).
So I think we will never see one single package of the whole distribution in
those, at least not officially released.

[Max Lapshin]

I can understand separation erlang package to erlang-nox, erlang-java
(because it can't be installed on 256MB VPS) and erlang-x11. But I
can't understand any other separation, because I've never heard about
anyone, who _has_ installed only what he wants.

[Alessandro Sivieri]

I also want to add that I think that Ubuntu 11.04 will have R14, because
Debian testing already has it, so I cannot see any good reason for not
having it; of course, if you are the official maintainer, then you may have
good reasons for it :)

[Vincenzo Di Somma]

I'm not the maintainer, I'm just very interested in having the best
possible Erlang story in both Ubuntu and Debian.

vds

[Alessandro Sivieri]

I have published Erlang R14 in my PPA (
http://launchpad.net/~scattino/+archive/ppa), in a tentative of direct
backport of the packages in Debian testing; if you want, you can try and use
it, it works for me(TM) but it may not for you, so please don't blame me for
that.

In summary: use it at your own risk; if you find it useful, good for you :)

[Max Lapshin]

Thank you a lot!

[Aaron Broad]

Hi all,

I'm trying to develop an wx application which requires SMP. But by default the emacs tools are leaving me in non-smp mode. How do I switch my default shell in emacs to an smp enabled one? NB: erl -smp works fine on the command prompt.

In ubuntu with latest version (tools-2.6.6.1)

thanks,
Aaron

[Aaron Broad]

Hi Aaron,

in /lib/tools-2.6.6.1/emacs/erlang.el

I switched the variable erlang-machine-opts to '("-smp") from '()

Now I can compile wx and run wx programs in emacs

Thanks:-),
Aaron

[Dan Gudmundsson]

C-u M-x erlang-shell
erl -smp +S12

> erlang:system_info(schedulers).
12

/Dan
PS: If you read/modified the code you could have seen that :-)

[zabrane Mikael]

Hi Dan & all,

Off topic question. Could someone please explain me what's
the benefits of this "+S" option (and the "+A" option by the way).
How to choose their values?

--
Regards
Zabrane

2010/11/2 Dan Gudmundsson <dg...@erlang.org>:

> C-u M-x erlang-shell
> erl -smp +S12
>
>> erlang:system_info(schedulers).
> 12

________________________________________________________________

[Scott Lystig Fritchie]

zabrane Mikael <zabr...@gmail.com> wrote:

mz> Off topic question. Could someone please explain me what's the
mz> benefits of this "+S" option (and the "+A" option by the way).

The +A option allows you to specify the size of the I/O worker thread
pool. For moderate and high workloads that involve the local file
system(*), you'll likely see a performance improvement by using it.

-Scott

(*) All UNIX variants that I'm aware of will ignore any request to
perform asynchronous I/O on the local file system unless you explicitly
use the async API. And even the async API doesn't have async versions
of some system calls like unlink(2).

[zabrane Mikael]

Thanks a lot Scott.

--
Regards
Zabrane

2010/11/5 Scott Lystig Fritchie <frit...@snookles.com>: