Ruby/Policy 2.0: Difference between revisions
< Ruby
(additionals) |
No edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 17: | Line 17: | ||
## '''gemfile''': projects based on the ''Gemfile'' or ''Rakefile'', for example rails or sinatra based projects like: [https://packages.altlinux.org/ru/sisyphus/srpms/foreman/specfiles foreman], keep their names as is; | ## '''gemfile''': projects based on the ''Gemfile'' or ''Rakefile'', for example rails or sinatra based projects like: [https://packages.altlinux.org/ru/sisyphus/srpms/foreman/specfiles foreman], keep their names as is; | ||
## '''complex''': gem grouped projects, name of which can't be unambiguously inferred, like: [https://packages.altlinux.org/ru/sisyphus/srpms/ruby-gnome2/specfiles gnome2], keep their names as is; | ## '''complex''': gem grouped projects, name of which can't be unambiguously inferred, like: [https://packages.altlinux.org/ru/sisyphus/srpms/ruby-gnome2/specfiles gnome2], keep their names as is; | ||
# Placement of the ruby site, vendor or gem modules is defined by [https://packages.altlinux.org/ru/sisyphus/binary/rpm-macros-ruby/ rpm-ruby-macros] package, which is generated by [https://packages.altlinux.org/ru/sisyphus/srpms/ruby ruby]; | # Placement of the ruby site, vendor or gem modules is defined by [https://packages.altlinux.org/ru/sisyphus/binary/rpm-macros-ruby/ rpm-ruby-macros] package, which is generated by [https://packages.altlinux.org/ru/sisyphus/srpms/ruby ruby]; | ||
# Conflicts | # Conflicts | ||
Line 28: | Line 27: | ||
## Versioning of the ruby modules is conforming original package's semantic versioning approach. | ## Versioning of the ruby modules is conforming original package's semantic versioning approach. | ||
## 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''' | ## 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''' | ||
# Dependencies | |||
## If it is required to use explicit dependencies the format of '''gem(gem_name) = %version''' is preferred before the '''gem-gem-name = %EVR''' one, since it set up the correct dependency to the gem, of course devel packages, which usually contains development headers and required to build the package dependencies, can be addressed with '''gem-gem-name-devel = %EVR''' form. |
Latest revision as of 01:46, 9 February 2024
Ruby Policy 2.0
Rules for ruby module and application packages
- 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:
- 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.
- gemfile: projects based on the Gemfile or Rakefile, for example rails or sinatra based projects like: foreman, keep their names as is;
- complex: gem grouped projects, name of which can't be unambiguously inferred, like: gnome2, keep their names as is;
- Placement of the ruby site, vendor or gem modules is defined by rpm-ruby-macros package, which is generated by ruby;
- Conflicts
- 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;
- Frequent version conflicts can be simply solved with specific ruby macros like of gem-nokogiri;
- In some cases maintainer is requiring to use lesser version of the ruby module, so there two approaches:
- downgrade package version with increment of epoch number (not recommended);
- build compatibility version package appending -compat suffix it package's name, like gem-smart-proxy-compat;
- Versioning
- Versioning of the ruby modules is conforming original package's semantic versioning approach.
- 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
- Dependencies
- If it is required to use explicit dependencies the format of gem(gem_name) = %version is preferred before the gem-gem-name = %EVR one, since it set up the correct dependency to the gem, of course devel packages, which usually contains development headers and required to build the package dependencies, can be addressed with gem-gem-name-devel = %EVR form.