Ruby/Packaging Notes

From ALT Linux Wiki
< Ruby
Revision as of 17:05, 12 December 2023 by Majioa (talk | contribs) (Created page with "== Packaging notes == === The 'ruby' package === In the system there is the only ''libruby'' library, with a single set of the ''stdlibs'' modules. When a new version of the ''libruby'' package has been built, all the ''stdlibs'' modules is rebuilt also, along with all gems that contain dynamically loaded ''.so'' libraries that conforms to the new version of ''libruby'', or where the ''Gemfile''/''.gemspec'' file pair contains explicit requirement to the ruby version i...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Packaging notes

The 'ruby' package

In the system there is the only libruby library, with a single set of the stdlibs modules.

When a new version of the libruby package has been built, all the stdlibs modules is rebuilt also, along with all gems that contain dynamically loaded .so libraries that conforms to the new version of libruby, or where the Gemfile/.gemspec file pair contains explicit requirement to the ruby version in.

External view of package

  1. packages that have been built from a gem, must have gem- prefix;
  2. source packages containing the rails, sinatra or similar applications can be without a prefix or have rubyapp- prefix;
  3. stdlibs modules along with other projects that don't belong to previous two points, and non-gem libraries must have ruby- prefix, and their files be placed into site_ruby folder;
  4. underscore chars "_" are replaced to minus '-' char in the names of packages.

Dependencies

  1. From now dependencies is being supervised based on Gemfile/.gemspec file pair analysis.
  2. Export of automatically calculated gem dependencies has view of gem(gemname) = version and rubygem(gemname) = version, the last form of the dependency has been kept to make them compatible to redhat ones.

Dependency conflict

In case of the dependency conflict is risen, one of the following ways to resolve them is applied:

  1. when and increase of a dependent gem version doesn't lead to degrade of workability of the parent gem, it is useful to apply explicit inline gem replacement by using ruby_use_gem_dependency, for example from >= 1.1.7 to >= 1.7 for gem named "gem_name", you shall to specify the only target version of the depending gem: 
    %ruby_use_gem_dependency gem_name >= 1.7
  2. since bundler allows keeping in the same tree of gems more than one version of each, but ALT packaging system doesn't allow making that thing, it is necessary to create an additional compatible package with the required version of the same gem. Name of the package must contain the same package name (as original non-compat), but also have full version including patch number fulled with "minus" chars. For example gem compat-gem will have full name gem-compat-gem-1-2-1.2.0.src.rpm;
  3. Gem dependencies, which there is building .so libraries from scources in, the dependency to current version of ruby is setup automatically, in order to rebuild of the ruby with a new version have forces to rebuild such kind of packages.

RPM Macros

Macros, which are required to gem and ruby-application packetizing, are defined in the rpm-build-ruby. And this file must be defined in spec with keyword BuilderRequires(pre), so we'll get BuildRequires(pre): rpm-build-ruby. This is require to build a package with any of kind ruby application gem or pure ruby.

According to the module folder separation in ruby documentation, vendor (in our case is the ALT) dependent modules have to be put into vendor folders, and end user modules, for example when a user is building ruby app in its computer, have to be put into site folders. ".so" libraries are to be put in arch dependent folders, for example %ruby_vendorarchdir, and ".rb" libraries are into just non-arch folders like %ruby_vendorlibdir.

Ruby folder and internal variable macros are the following: 

# ruby file and folder macros
%ruby_gemspecdir        /usr/lib/ruby/gemie/specifications
%ruby_gemsextdir        /usr/lib64/ruby/gemie/extensions
%ruby_gemslibdir        /usr/lib/ruby/gemie/gems
%ruby_gemsdocdir        /usr/share/ri
%ruby_includedir        /usr/include
%ruby_gemspec           %ruby_gemspecdir/%gemname-%version.gemspec
%ruby_gemextdir         %ruby_gemsextdir/%gemname-%version
%ruby_gemlibdir         %ruby_gemslibdir/%gemname-%version
%ruby_gemdocdir         %ruby_gemsdocdir/%gemname-%version
%ruby_gemincludedir     %ruby_includedir/%gemname
%ruby_sitedocdir        /usr/share/ri
%ruby_sitearch          x86_64-linux
%ruby_sitearchdir       /usr/local/lib64/ruby
%ruby_sitelibdir        /usr/local/lib/ruby
%ruby_siteincludedir    /usr/include/ruby
%ruby_vendorhdrdir      /usr/include/vendor_ruby
%ruby_vendorarchdir     /usr/lib64/ruby/vendor_ruby/
%ruby_vendorlibdir      /usr/lib/ruby/vendor_ruby
%ruby_vendorarchhdrdir  /usr/include/vendor_ruby

Files placement

The library files for a gem must be placed to the proper subfolders for the gem in /usr/lib/ruby/gems/2.5.0/, where 2.5.0 is the current ruby version, without a patch number.

Package specification notes

  1. all the packages containing the main code (meaning ruby and dynamic libraries) of the gem, must have the Development/Ruby group, and packages containing executables must have group name that belongs to its purpose.
  2. packages, which is not containing any kind of architecture-dependent binaries, must have a declaration of noarch architecture explicitly.