On Tue, Jan 08, 2013 at 01:46:41PM +0400, Matwey V. Kornilov wrote:
Michal Vyskocil wrote:
1. Names. I suggest erlang-* convention naming (like python-, ruby-, etc...). Some existing packages have to be renamed (pure technical moment).
Does it makes a sense to have erlang-ejabberd and similar? I would use erlang- prefix for bindings and libraries only.
Yes, I was not precise. Library applications are erlang-$UPSTREAM_NAME, standalone application are $UPSTREAM_NAME. Compare with rabbitmq-server (server daemon) and erlang-rabbitmq-client (library to write client application in erlang).
Nice!
4. /src subtree. My suggestion is not to pack sources at all, or pack it as separate package. (Compare with erlang and erlang-src)
Isn't packaging /src subtree pointless, if you will build all with +debug_info? Erlang documentation says the source code can be reconstructed if module built with +debug_info.
The sources are still useful for reference. Fedora approach ([2] from your list) answers this question: no sources.
The second related question is possible desire to split into erlang-myapp, erlang-myapp-devel, erlang-myapp-src.
I cannot tell you, what would be easier - if having sources in separate package will help you somehow, then I don't see a reason to not package it.
5. Versions (A). Some libraries at github don't have any tags or releases, this is for us to decide how to enumerate packages. My suggestion is 1) to ask upstream maintainer to apply tags and releases 2) to use _service:tar_scm and _service:set_version to enumerate git master by UNIX timestamps (This is the most automatic and simple way).
There's just one risc - if upstream decides to start with a versioning, we have a problem with our version 2013.
http://en.opensuse.org/openSUSE:Packaging_Go suggests the better approach. Versions like 0.0.0+git20110521. This problem is not erlang-related only. Many applications avoid to use versions and we have zoo at http://en.opensuse.org/Package_list
0.9.8_git201104301110 0.1.0_git20110905 2.7.8+git20120223
We don't have general rule for this (as far as I see), so my new proposal to use 'Go notation': 0.0.0+gitYYYYMMDD, 0.0.0+hgYYYYMMDD, 0.0.0+svnREVISION
Yes, the Go's approach makes a good sense and should be prefered! And looking at our guidelines, this topic is not documented!
6. Versions (B1). Every erlang library (application) have to have .app file with 'vsn' field where its version is indicated. The library location must be in agreement with this version and application name. I.e, if we have
{application, myapp, [{description, "myapp My Erlang Application"}, {vsn, "1.2.3"},
then correct place is "/usr/lib/erlang/lib/myapp-1.2.3/". We have to provide some lint-checks and rpm-macros to check this and to simplify packaging.
7. Versions (B2). 'vsn' and appname often don't coincide with upstream git reponame and tag/release. My suggestion is 1) to ask upstream maintainer to sort the things out 2) to use upstream name and upstream version as name and version of RPM package, and to generate location from .app-file. (some rpm- macros have to be written to simplify).
I'm afraid that only 1) is the correct way - otherwise we will ends with every distro having own it's own versioning for such things.
'vsn' should be thought as of kind of abi/api-compatibility enumeration. It is ok to have /usr/lib/libdc1394.so.22.1.7 in package libdc1394-2.2.0. Even now, erlang-dialyzer-R15B03 provides /usr/lib/erlang/lib/dialyzer-2.5.3 and I don't see any problems with such version dichotomy.
OK - it might be good to invent a special provides for erlang modules - like Provides: erlang(dialyzer) = 2.5.3 in this case. It is something the proposed beam2spec can do and will enhance a cross-distro compatibility.
8. noarch. BEAM bytecode is platform independent, AFAIK. Should we build packages as noarch?
If it's independent, then yes, please build it as noarch.
It arch-depends only on installation-path %{_libdir}/erlang/lib. We have to find the way to separate this (like in python) into %{_libdir}/erlang/lib and /usr/lib/erlang/lib.
It is worth mention that erlang is built and works successfully on arm5 and arm7 as well. In this case, noarch means not only i586 and x86_64. The general rule would be to use noarch if you don't build with +native (HiPE) or provide binaries like .so and ELF executables.
Makes a sense.
BTW: it is probably a good idea to contact Fedora guys around Erlang [1][2] to share as much things as we can
Yep, before wrote this, I already had had a conversation with Peter Lemenkov, who is Fedora's maintainer of erlang stuff.
Nice! Regards Michal Vyskocil