Ruby/Policy 2.0

From ALT Linux Wiki
< Ruby
Revision as of 16:37, 19 December 2023 by Majioa (talk | contribs) (additionals)
Stub.png
Sisyphus Policy draft
Authur(s) — Малъ Скрылевъ
Discussion in devel@
Discussed since 05.02.2019


Ruby Policy 2.0

Rules for ruby module and application packages

  1. The name of package depends on the repo containments and there is of three main types, so list below shows types and their according namings:
    1. gem: project contains one of several gems depending of one of the contained gems, like: concurrent-ruby, train, have to be renamed with one, which begins with gem- prefix of shorest gem included in repo, with replacement '_', and '.' chars into '-', like name smart_proxy.one has to become gem-smart-proxy-one when packaged.
    2. gemfile: projects based on the Gemfile or Rakefile, for example rails or sinatra based projects like: foreman, keep their names as is;
    3. complex: gem grouped projects, name of which can't be unambiguously inferred, like: gnome2, keep their names as is;
  2. All the build requires and conflicts should, except those that must be used for build, be closed under check condition, and it required only for testing purposes;
  3. Placement of the ruby site, vendor or gem modules is defined by rpm-ruby-macros package, which is generated by ruby;
  4. Conflicts
    1. To solve name conflict, for example if there are gem name like gem.name and gem_name that gives the same package name, alternate secondary packages must have -alt suffix in their names;
    2. Frequent version conflicts can be simply solved with specific ruby macros like of gem-nokogiri;
    3. In some cases maintainer is requiring to use lesser version of the ruby module, so there two approaches:
      1. downgrade package version with increment of epoch number (not recommended);
      2. build compatibility version package appending -compat suffix it package's name, like gem-smart-proxy-compat;
  5. Versioning
    1. Versioning of the ruby modules is conforming original package's semantic versioning approach.
    2. In case if a maintainer requires to apply changes to a module, for example, either with a patch, or/and from a specific commit from the git tree, it should add a patch version counting from the nearest back release to the current commit, to affect gemspec version change, and the add "zero" right after -alt release, like alt-0.1 instead of -alt1