On Fri, Jan 04, 2013 at 06:05:55PM +0400, Matwey V. Kornilov wrote:
Hi,
I am a maintainer at devel:languages:erlang, and current problem is that we do not have guidelines for Erlang libraries (packages). I would like to discuss this situation. The guidelines are subject to decide and to agree. I list some issues and possible options for each. Next, I would like to put in discussion some additional ideas to further development.
Hi Matwey, thanks for bringing this topic here.
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.
2. Group. As for me, It is clear: "Development/Languages/Other"
3. +debug_info. Should we build beam-code with +debug_info, or without? I suggest to build everything with +debug_info, this makes dumps more informative not only for development but for runtime production also.
That's probably a good idea - looking at documentation, it seems erlang uses it's own format, so there's probably no way how to split it to separate file, like DWARF can. But this might be done in a future.
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.
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.
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.
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. BTW: it is probably a good idea to contact Fedora guys around Erlang [1][2] to share as much things as we can [1] http://fedoraproject.org/wiki/Erlang [2] http://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines Regards Michal Vyskocil