Hi, I. Introduction. This is to highlight rpmlint efforts to support erlang based application and libraries. In home:matwey:erlang project, there are packages rebuilt with customized version of rpmlint. Four basic tests has been implemented, some of them are just for demonstration, other may be quite helpful for package maintainers. 1. beam-consists-compile-time Every beam file has six-tuple in CInf chunk, For instance, (2013, 5, 8, 12, 9, 19). Actually, we are not able to remove this information now (but we do want, I suppose). So, this test is mostly for fun. 2. beam-compiled-without-debug_info We can check whether the file has been compiled with turned on debug_info. This is considered as quite desirable by both Fedora and openSUSE packagers. 3. beam-was-not-recompiled Every beam file also tracks filename of the source file from which it has been compiled. Let us take a look at example from real life: [ 1297s] erlang.i586: W: beam-was-not-recompiled /usr/lib/erlang/lib/erts-5.10.1/ebin/zlib.beam /ldisk/egil/git/otp/erts/preloaded/src/zlib.erl [ 1297s] erlang.i586: W: beam-was-not-recompiled /usr/lib/erlang/lib/erts-5.10.1/ebin/prim_zip.beam /ldisk/egil/git/otp/erts/preloaded/src/prim_zip.erl [ 1297s] erlang.i586: W: beam-was-not-recompiled /usr/lib/erlang/lib/erts-5.10.1/ebin/otp_ring0.beam /ldisk/egil/git/otp/erts/preloaded/src/otp_ring0.erl These three files have been compiled from files located at /ldisk/... and obviously it was not inside the OBS. This is quite serious issue, because we can not guarantee that compiled code corresponds to the sources. This leads to paranoid security issues. 4. beam-import-not-found The most sophisticated test. It was inspired by experiments with auto requires/provides for erlang. Erlang has dynamic linking at runtime, so at compile time you can compile a module which requires a function which may even not exist in the whole universe. This makes the packages potentially broken. Even the function really exists in some module, the packager may forget to add proper Requires. Let us again take a look at example from real life: [ 53s] erlang-rfc4627.i586: W: beam-import-not-found /usr/lib/erlang/lib/rfc4627_jsonrpc-0.01/ebin/rfc4627_jsonrpc_cowboy.beam cowboy_http_req:method/1 [ 53s] erlang-rfc4627.i586: W: beam-import-not-found /usr/lib/erlang/lib/rfc4627_jsonrpc-0.01/ebin/rfc4627_jsonrpc_cowboy.beam cowboy_http_req:raw_path/1 [ 53s] erlang-rfc4627.i586: W: beam-import-not-found /usr/lib/erlang/lib/rfc4627_jsonrpc-0.01/ebin/rfc4627_jsonrpc_cowboy.beam cowboy_http_req:headers/1 This package has (optional) interface for cowboy http server. But we don't have rpm package with cowboy http server at all. This case is not so critical, because there are other interfaces. But maybe this package should be split to erlang-rfc4627, erlang-rfc4627-cowboy, erlang-rfc4627-http. This test is quite limited by rpmlint functionality. Cross-dependencies between packages generated from a single .spec are impossible to properly detect and this leads to false-positives. Maybe this should be redesigned to incorporate rules how to specify Requires/Provides for erlang. II. Under the hood. There is python module pybeam https://github.com/matwey/pybeam that is able to efficiently parse whole beam file and represent it as python object. This module is based on quite powerful python-construct module, that is able to parse and build binary structured data. The CheckErlang.py (module for rpmlint) is located at https://github.com/matwey/rpmlint-checks III. So what? Ok, this surely requires further testing, bug-hunting and discussion. But now, I would like to get some feedback from opensuse rpmlint maintainers and everyone to whom this all may concern. And surely, I think sooner or later this should be included into our factory rpmlint. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org