[opensuse-packaging] RFC: Guidelines change: Erlang
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
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
Michal Vyskocil wrote:
On Fri, Jan 04, 2013 at 06:05:55PM +0400, Matwey V. Kornilov wrote:
[...] 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.
You can prefix the timestamp with a fake version, like 0_$timestamp or 0.0_$timestamp to make sure those snapshots are considered older than the expected real versions. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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).
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.
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
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.
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.
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. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
Michal Vyskocil wrote:
'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.
This is one of the must-to-have things. Erlang libraries and applications depend on each other. Until we have auto-requires/auto-provides, we have to do this by hands. This is important thing to add to guidelines. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Here is a sketch of the draft: http://en.opensuse.org/User:Matwey/Erlang_guidelines_draft I think this will reinforce the discussion. I hope everybody has editing access to there. First version turned out to be quite twitchy. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (3)
-
Ludwig Nussel -
Matwey V. Kornilov -
Michal Vyskocil