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. 1. Names. I suggest erlang-* convention naming (like python-, ruby-, etc...). Some existing packages have to be renamed (pure technical moment). 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. 4. /src subtree. My suggestion is not to pack sources at all, or pack it as separate package. (Compare with erlang and erlang-src) 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). 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). 8. noarch. BEAM bytecode is platform independent, AFAIK. Should we build packages as noarch? Further ideas: I. An analogous to py2pack to generate spec-templates from .app files or rebar settings of project. II. Automatic Requires/Provides checking for erlang. Some BEAM-code inspection is needed to produce the lists of exported and required symbols/modules. Remember, erlang has common namespace. Functions from different modules and packages may interfere with each other. p.s. So, gentlemen, please give me the feedback. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org