Ruby/Policy 2.0: Difference between revisions
< Ruby
(additionals) |
|||
Line 19: | Line 19: | ||
# 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; | # 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; | ||
# 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 | |||
## 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 [https://packages.altlinux.org/ru/sisyphus/srpms/gem-nokogiri/specfiles/ 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 [https://packages.altlinux.org/ru/sisyphus/srpms/gem-smart-proxy-compat/specfiles 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''' |
Revision as of 16:37, 19 December 2023
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;
- 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;
- 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