#796 ruby: fix markup and add missing notes
Merged 9 months ago by ignatenkobrain. Opened 10 months ago by ignatenkobrain.
ignatenkobrain/packaging-committee ruby  into  master

@@ -1,12 +1,12 @@ 

  = Ruby Packaging Guidelines

  

- __TOC__

+ NOTE: *JRuby Gems*: Although Fedora has fully functioning JRuby integrated with system RubyGems, we have decided to not include the JRuby specific packaging guidelines here, as they need some more work. They will appear here as soon as we feel that we've got everything covered properly. You can contact us on https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org/[Ruby-SIG mailing list] in case of any questions about the prepared JRuby packaging guidelines.

  

- There are three basic categories of ruby packages: link:#RubyGems[ ruby gems], link:#Non-Gem_Packages[ non-gem ruby packages], and link:#ruby_applications[ applications written in ruby]. These guidelines contain sections common to all of these as well as sections which apply to each one individually. Be sure to read all the guidelines relevant to the type of ruby package you are building.

+ There are three basic categories of ruby packages: <<RubyGems>>, <<Non-Gem Packages,non-gem Ruby packages>>, and <<Applications,applications written in Ruby>>. These guidelines contain sections common to all of these as well as sections which apply to each one individually. Be sure to read all the guidelines relevant to the type of ruby package you are building.

  

  == Ruby Compatibility

  

- Each Ruby package MUST indicate it depends on a Ruby interpreter (this does not apply to link:#RubyGems[ruby gem packages]). Use ruby(release) virtual requirement to achieve that:

+ Each Ruby package MUST indicate it depends on a Ruby interpreter (this does not apply to <<RubyGems>>). Use `ruby(release)` virtual requirement to achieve that:

  

  ....

  Requires: ruby(release)

@@ -18,14 +18,18 @@ 

  Requires: ruby(release) >= 1.9.1

  ....

  

+ NOTE: *Alternate interpreters*: Alternate Ruby interpreters (currently JRuby) also `Provide: ruby(release)`. This implies, that pure RubyGems packages (these are shared among interpreters) SHOULD NOT have `Requires: ruby` or `Requires: jruby` to have their dependencies satisfied by any of these interpreters.

+ 

+ WARNING: *Over specified ruby(release) versioning*: Please note, that if the `ruby(release)` version requirement is too specific, it might cause an unexpected interpreter to be drawn in. E.g. `ruby(release) = 1.8` will require JRuby package, since it is the only package that provides it.

+ 

  === Different Interpreters Compatibility

  

- Most of the pure Ruby packages will work on all Ruby interpreters. There are however cases, when the packages use interpreter-specific functions (like `+fork()+`) and won't run on other interpreters (JRuby). In this case, the package SHOULD require that interpreter. For example, a package that uses `+fork+` SHOULD explicitly specify `+Requires: ruby+`.

+ Most of the pure Ruby packages will work on all Ruby interpreters. There are however cases, when the packages use interpreter-specific functions (like `fork()`) and won't run on other interpreters (JRuby). In this case, the package SHOULD require that interpreter. For example, a package that uses `fork` SHOULD explicitly specify `Requires: ruby`.

  In case of such package, packager SHOULD file a bug to ask upstream to provide support for other interpreter(s). This SHOULD be documented in specfile.

  

  === Shebang lines

  

- On Fedora, `+/usr/bin/ruby+` is implemented via https://github.com/bkabrda/rubypick[Rubypick]. Rubypick is a tool similar to RVM or rbenv. It allows choosing interpreter to execute Ruby script. Rubypick routes anything executed via `+/usr/bin/ruby+` to `+/usr/bin/ruby-mri+` or `+/usr/bin/jruby+`. By default, it runs MRI (Matz's Ruby Implementation), but user can explicitly specify the interpreter by using `+_mri_+` or `+_jruby_+` as a first parameter. For example:

+ On Fedora, `/usr/bin/ruby` is implemented via https://github.com/bkabrda/rubypick[Rubypick]. Rubypick is a tool similar to RVM or rbenv. It allows choosing interpreter to execute Ruby script. Rubypick routes anything executed via `/usr/bin/ruby` to `/usr/bin/ruby-mri` or `/usr/bin/jruby`. By default, it runs MRI (Matz's Ruby Implementation), but user can explicitly specify the interpreter by using `+_mri_+` or `+_jruby_+` as a first parameter. For example:

  

  ....

  ruby _jruby_ jruby_script.rb

@@ -33,7 +37,7 @@ 

  rails _jruby_ s

  ....

  

- Using the `+RUBYPICK+` environment variable can achieve the same results. The environment variable can be used to set one interpreter as the global default:

+ Using the `RUBYPICK` environment variable can achieve the same results. The environment variable can be used to set one interpreter as the global default:

  

  ....

  export RUBYPICK=_jruby_

@@ -47,57 +51,95 @@ 

  

  * Packages that contain Ruby Gems MUST be called `+rubygem-%{gem_name}+`.

  

- * The name of a ruby extension/library package MUST start with the interpreter it is built for (ruby, jruby, etc) and then the `+UPSTREAM+` name. For example: `+ruby-UPSTREAM+`. If the upstream name `+UPSTREAM+` contains `+ruby+`, that SHOULD be dropped from the name. For example, the SQLite database driver for ruby is called `+sqlite3-ruby+`. The corresponding Fedora package SHOULD be called `+ruby-sqlite3+`, and not `+ruby-sqlite3-ruby+`.

+ * The name of a ruby extension/library package MUST start with the interpreter it is built for (ruby, jruby, etc) and then the `UPSTREAM` name. For example: `ruby-UPSTREAM`. If the upstream name `UPSTREAM` contains `ruby`, that SHOULD be dropped from the name. For example, the SQLite database driver for ruby is called `sqlite3-ruby`. The corresponding Fedora package SHOULD be called `ruby-sqlite3`, and not `ruby-sqlite3-ruby`.

  

- * Application packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the general link:Packaging/NamingGuidelines[ NamingGuidelines] instead.

+ * Application packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the general xref:Naming.adoc[Naming Guidelines] instead.

  

  == Macros

  

- Non-gem ruby packages and ruby gem packages install to certain standard locations. The `+ruby-devel+` and `+rubygems-devel+` packages contain macros useful for the respective package types. Alternate ruby interpreters will have equivalent locations (To be added to this table later)

- 

- [cols=",,",options="header",]

- |===================================================================================================================

- |Macro |Expanded path |Usage

- |From ruby-devel; intended for non-gem packages.

- |`+%{ruby_vendorarchdir}+` |/usr/lib\{64}/ruby/vendor_ruby |Place for architecture specific (e.g. *.so) files.

- |`+%{ruby_vendorlibdir}+` |/usr/share/ruby/vendor_ruby |Place for architecture independent (e.g. *.rb) files.

- |`+%{ruby_sitearchdir}+` |/usr/local/lib\{64}/ruby/site_ruby |Place for local architecture specific (e.g. *.so) files.

- |`+%{ruby_sitelibdir}+` |/usr/local/share/ruby/site_ruby |Place for local architecture independent (e.g. *.rb) files.

- |From rubygems-devel; intended for gem packages

- |`+%{gem_dir}+` |/usr/share/gems |Top directory for the Gem structure.

- |`+%{gem_instdir}+` |%\{gem_dir}/gems/%\{gem_name}-%\{version} |Directory with the actual content of the Gem.

- |`+%{gem_libdir}+` |%\{gem_instdir}/lib |The `+lib+` folder of the Gem.

- |`+%{gem_cache}+` |%\{gem_dir}/cache/%\{gem_name}-%\{version}.gem |The cached Gem.

- |`+%{gem_spec}+` |%\{gem_dir}/specifications/%\{gem_name}-%\{version}.gemspec |The Gem specification file.

- |`+%{gem_docdir}+` |%\{gem_dir}/doc/%\{gem_name}-%\{version} |The rdoc documentation of the Gem.

- |`+%{gem_extdir_mri}+` |%\{_libdir}/gems/ruby/%\{gem_name}-%\{version} |The directory for MRI Ruby Gem extensions.

- |===================================================================================================================

+ Non-gem ruby packages and ruby gem packages install to certain standard locations. The `ruby-devel` and `rubygems-devel` packages contain macros useful for the respective package types. Alternate ruby interpreters will have equivalent locations (To be added to this table later)

+ 

+ [%header,cols="1,2,1"]

+ |===

+ |Macro

+ |Expanded path

+ |Usage

+ 

+ 3+|*From ruby-devel; intended for non-gem packages.*

+ 

+ |`+%{ruby_vendorarchdir}+`

+ |`+/usr/lib{64}/ruby/vendor_ruby+`

+ |Place for architecture specific (e.g. *.so) files.

+ 

+ |`+%{ruby_vendorlibdir}+`

+ |`+/usr/share/ruby/vendor_ruby+`

+ |Place for architecture independent (e.g. *.rb) files.

+ 

+ |`+%{ruby_sitearchdir}+`

+ |`+/usr/local/lib{64}/ruby/site_ruby+`

+ |Place for local architecture specific (e.g. *.so) files.

+ 

+ |`+%{ruby_sitelibdir}+`

+ |`+/usr/local/share/ruby/site_ruby+`

+ |Place for local architecture independent (e.g. *.rb) files.

+ 

+ 3+|*From rubygems-devel; intended for gem packages.*

+ 

+ |`+%{gem_dir}+`

+ |`+/usr/share/gems+`

+ |Top directory for the Gem structure.

+ 

+ |`+%{gem_instdir}+`

+ |`+%{gem_dir}/gems/%{gem_name}-%{version}+`

+ |Directory with the actual content of the Gem.

+ 

+ |`+%{gem_libdir}+`

+ |`+%{gem_instdir}/lib+`

+ |The `lib` folder of the Gem.

+ 

+ |`+%{gem_cache}+`

+ |`+%{gem_dir}/cache/%{gem_name}-%{version}.gem+`

+ |The cached Gem.

+ 

+ |`+%{gem_spec}+`

+ |`+%{gem_dir}/specifications/%{gem_name}-%{version}.gemspec+`

+ |The Gem specification file.

+ 

+ |`+%{gem_docdir}+`

+ |`+%{gem_dir}/doc/%{gem_name}-%{version}+`

+ |The rdoc documentation of the Gem.

+ 

+ |`+%{gem_extdir_mri}+`

+ |`+%{_libdir}/gems/ruby/%{gem_name}-%{version}+`

+ |The directory for MRI Ruby Gem extensions.

+ 

+ |===

  

  === Interpreter independence and directory macros

  

- You might have noticed that the table above has different directories for non-gem libraries on different ruby interpreters but only a single set of directories for rubygem libraries. This is because code written for one ruby interpreter will often run on all ruby interpreters that Fedora ships (ruby, jruby, etc). However, some code uses methods that are not available on all interpreters (see link:#interpreter_compatibility[Different Interpreters Compatibility]). Rubygems have a facility to ship different versions of the code in the same gem so that the gem can run on all versions of the interpreter so we only need to have one common directory for rubygems that all the interpreters can use.

+ You might have noticed that the table above has different directories for non-gem libraries on different ruby interpreters but only a single set of directories for rubygem libraries. This is because code written for one ruby interpreter will often run on all ruby interpreters that Fedora ships (ruby, jruby, etc). However, some code uses methods that are not available on all interpreters (see <<Different Interpreters Compatibility>>). Rubygems have a facility to ship different versions of the code in the same gem so that the gem can run on all versions of the interpreter so we only need to have one common directory for rubygems that all the interpreters can use.

  

  The standard ruby `+%{vendorlib}+` directories lack this facility. For this reason, non-gem libraries need to be placed in per-interpreter directories and MUST have a separate subpackage (or package depending on upstream) for each interpreter that they support.

  

  == Libraries

  

- These guidelines only apply to Ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the link:#ruby_applications[ruby applications guidelines] instead.

+ These guidelines only apply to Ruby packages whose main purpose is providing a Ruby library; packages that mainly provide user-level tools that happen to be written in Ruby MUST follow the <<Applications,Ruby applications Guidelines>> instead.

  

  === RubyGems

  

- http://www.rubygems.org/[RubyGems] are Ruby's own packaging format. Gems contain a lot of the same metadata that RPM's need, making fairly smooth interoperation between RPM and Gems possible. This guideline ensures that Gems are packaged as RPM's in a way that such RPM's fit cleanly with the rest of the distribution and to make it possible for the end user to satisfy dependencies of a Gem by installing the appropriate RPM-packaged Gem.

+ https://rubygems.org/[RubyGems] are Ruby's own packaging format. Gems contain a lot of the same metadata that RPM's need, making fairly smooth interoperation between RPM and Gems possible. This guideline ensures that Gems are packaged as RPM's in a way that such RPM's fit cleanly with the rest of the distribution and to make it possible for the end user to satisfy dependencies of a Gem by installing the appropriate RPM-packaged Gem.

  

  Both RPM's and Gems use similar terminology --- there are specfiles, package names, dependencies etc. for both. To keep confusion to a minimum, terms relating to Gem concepts will be explicitly refereed to with the word 'Gem' prefixed, eg 'Gem specification' (.gemspec). An unqualified 'package' in the following always means an RPM.

  

  * Spec files MUST contain a definition of `+%{gem_name}+` which is the name from the Gem's specification.

- * The `+Source+` of the package MUST be the full URL to the released Gem archive; the version of the package MUST be the Gem's version.

- * The package MUST `+BuildRequires: rubygems-devel+` to pull in the macros needed to build.

- * There SHOULD NOT be any rubygem `+Requires+` nor `+Provides+` listed, since those are autogenerated.

- * There SHOULD NOT be `+Requires: ruby(release)+`, unless you want to explicitly specify Ruby version compatibility. Automatically generated dependency on RubyGems (`+Requires: ruby(rubygems)+`) is enough.

+ * The `Source` of the package MUST be the full URL to the released Gem archive; the version of the package MUST be the Gem's version.

+ * The package MUST `BuildRequires: rubygems-devel` to pull in the macros needed to build.

+ * There SHOULD NOT be any rubygem `Requires` nor `Provides` listed, since those are autogenerated.

+ * There SHOULD NOT be `Requires: ruby(release)`, unless you want to explicitly specify Ruby version compatibility. Automatically generated dependency on RubyGems (`Requires: ruby(rubygems)`) is enough.

  

  ==== Filtering Requires and Provides

  

- Runtime requires and provides are automatically generated by RPM's dependency generator. However, it can sometimes throw in additional dependencies contrary to reality. To fix this, the dependency generator needs to be overridden so that the additional dependencies can be filtered out. See Packaging:AutoProvidesAndRequiresFiltering for details.

+ Runtime requires and provides are automatically generated by RPM's dependency generator. However, it can sometimes throw in additional dependencies contrary to reality. To fix this, the dependency generator needs to be overridden so that the additional dependencies can be filtered out. See xref:AutoProvidesAndRequiresFiltering.adoc[AutoProvidesAndRequiresFiltering] for details.

  

  ==== Building gems

  

@@ -136,26 +178,28 @@ 

  

  ===== %prep

  

- RPM (as of 4.14) can directly unpack gem archives, so we can call `+gem unpack+` to extract the source from the gem. Then we call `+%setup -n %{gem_name}-%{version}+` to tell rpm what the directory the gem has unpacked into. At the same directory level, the %\{gem_name}-%\{version}.gemspec file is created automatically as well. This `+.gemspec+` file will be used to rebuild the gem later. If we need to modify the `+.gemspec+` (for instance, if the version of dependencies is wrong for Fedora or the `+.gemspec+` is using old, no longer supported fields) we would do it here. Patches to the code itself can also be done here.

+ RPM (as of 4.14) can directly unpack gem archives, so we can call `gem unpack` to extract the source from the gem. Then we call `+%setup -n %{gem_name}-%{version}+` to tell rpm what the directory the gem has unpacked into. At the same directory level, the %\{gem_name}-%\{version}.gemspec file is created automatically as well. This `.gemspec` file will be used to rebuild the gem later. If we need to modify the `.gemspec` (for instance, if the version of dependencies is wrong for Fedora or the `.gemspec` is using old, no longer supported fields) we would do it here. Patches to the code itself can also be done here.

  

  ===== %build

  

- Next we build the gem. Because `+%gem_install+` only operates on gem archives, we next recreate the gem with `+gem build+`. The gem file that is created is then used by `+%gem_install+` to build and install the code into the temporary directory, which is `+./%{gem_dir}+` by default. We do this because the `+%gem_install+` command both builds and installs the code in one step so we need to have a temporary directory to place the built sources before installing them in `+%install+` section.

+ Next we build the gem. Because `+%gem_install+` only operates on gem archives, we next recreate the gem with `gem build`. The gem file that is created is then used by `+%gem_install+` to build and install the code into the temporary directory, which is `+./%{gem_dir}+` by default. We do this because the `+%gem_install+` command both builds and installs the code in one step so we need to have a temporary directory to place the built sources before installing them in `+%install+` section.

  

  `+%gem_install+` macro accepts two additional options:

  

- `+-n +`::

+ -n <gem_file>::

    Allows to override gem used for installation. This might get useful for converting legacy spec, so you might specify %\{SOURCE0} as a gem for installation.

- `+-d +`::

+ -d <install_dir>::

    Might override the gem installation destination. However we do not suggest to use this option.

  

+ NOTE: The `+%gem_install+` macro MUST NOT be used to install into the `+%{buildroot}+`

+ 

  ===== %install

  

  Here we actually install into the `+%{buildroot}+`. We create the directories that we need and then copy what was installed into the temporary directories into the `+%{buildroot}+` hierarchy. Finally, if this ruby gem creates shared objects the shared objects are moved into the arch specific `+%{gem_extdir_mri}+` path.

  

  ==== Patching required gem versions

  

- One common patching need is to change overly strict version requirements in the upstream `+.gemspec+`. This could be because upstream's `+.gemspec+` only mentions versions that they've explicitly tested against but we know that a different version will also work or because we know that the packages we ship have applied fixes for problematic behavior without bumping the version number (for instance, backported fixes). To adjust such dependencies, you can use the `+%gemspec_add_dep+` and `+%gemspec_remove_dep+` macros.

+ One common patching need is to change overly strict version requirements in the upstream `.gemspec`. This could be because upstream's `.gemspec` only mentions versions that they've explicitly tested against but we know that a different version will also work or because we know that the packages we ship have applied fixes for problematic behavior without bumping the version number (for instance, backported fixes). To adjust such dependencies, you can use the `+%gemspec_add_dep+` and `+%gemspec_remove_dep+` macros.

  

  For example, if you wanted to use any version of Aruba instead of the overly specific version requested by upstream, you could use in `+%prep+` section following two lines:

  

@@ -164,16 +208,24 @@ 

  %gemspec_add_dep -g aruba

  ....

  

+ CAUTION: *Use macros only on top of generated .gemspec*: The `+%gemspec_add_dep+` and `+%gemspec_remove_dep+` macros work reliably only on .gemspec generated using the ruby spec command. Please don't use the macros on upstream .gemspec files.

+ 

+ IMPORTANT: *Be sure to test*: Do not simply change versions without testing that the new version works. There are times the upstream is overly strict but there are also times when the version requirement was specified because a specific bug was encountered or the API changed in a minor release.

+ 

  === Packaging for Gem and non-Gem use

  

+ IMPORTANT: *Packaging for non-Gem use is no longer needed*: Originally, rubygem modules were not placed in ruby's library path, so we packaged rubygems for use with both gems and non-gems. This allowed code that used `require('ARubyModulePackagedAsAGem');` to function. The current `rubygem` module adds all gems to the ruby library path when it is require'd. So, packagers MUST NOT create non-Gem subpackages of rubygems for new packages. Since the majority of Ruby packages in Fedora are now packaged as installed gems, you might need to patch the code to use `require('rubygem')` as early in the program as possible to ensure that these ruby components are properly found. Packages for ruby gems that currently create a non-gem subpackage SHOULD be adapted to stop shipping the non-gem subpackage (with a xref:index.adoc#renaming-or-replacing-existing-packages[proper Obsoletes and Provides] in the main rubygem package).

+ 

  === Non-Gem Packages

  

- Non-Gem Ruby packages MUST require ruby-devel package at build time with a `+BuildRequires: ruby-devel+`, and MAY indicate the minimal ruby version they need for building.

+ Non-Gem Ruby packages MUST require ruby-devel package at build time with a `BuildRequires: ruby-devel`, and MAY indicate the minimal ruby version they need for building.

  

  ==== Build Architecture and File Placement

  

  The following only affects the files that the package installs into `+%{ruby_vendorarchdir}+` and `+%{ruby_vendorlibdir}+` (the actual Ruby library files). All other files in a Ruby package MUST adhere to the general Fedora packaging conventions.

  

+ IMPORTANT: *Site versus Vendor*: Previously, `+%{ruby_sitelibdir}+` and `+%{ruby_sitearchdir}+` were used. However, as they are meant only for local installations, please use `+%{ruby_vendorlibdir}+` and `+%{ruby_vendorarchdir}+` instead.

+ 

  ==== Pure Ruby packages

  

  Pure Ruby packages MUST be built as noarch packages.

@@ -186,13 +238,13 @@ 

  

  The binary files in a Ruby package with binary content MUST be placed into `+%{ruby_vendorarchdir}+` (or its proper subdirectory). The Ruby files in such a package SHOULD be placed into %\{ruby_vendorlibdir}. The specfile MUST use these macros.

  

- For packages which create C shared libraries using `+extconf.rb+`

+ For packages which create C shared libraries using `extconf.rb`

  

  ....

  export CONFIGURE_ARGS="--with-cflags='%{optflags}'"

  ....

  

- SHOULD be used to pass `+CFLAGS+` to `+Makefile+` correctly. Also, to place the files into the correct folders during build, pass `+--vendor+` to `+extconf.rb+` like this:

+ SHOULD be used to pass `CFLAGS` to `Makefile` correctly. Also, to place the files into the correct folders during build, pass `--vendor` to `extconf.rb` like this:

  

  ....

  extconf.rb --vendor

@@ -211,7 +263,7 @@ 

  %global app_root %{_datadir}/%{name}

  ....

  

- These packages typically have no `+Provides+` section, since no other libraries or applications depend on them.

+ These packages typically have no `Provides` section, since no other libraries or applications depend on them.

  

  Here's an abbreviated example:

  

@@ -286,7 +338,7 @@ 

  #...

  ....

  

- Note, that although the source is a RubyGem, we have to install the files manually under %\{_datadir}/%\{name}, %\{_bindir}, etc. to follow FHS and general packaging guidelines. If additional Fedora specific files (systemd `+.service+` files, configurations) are required, they SHOULD be

+ Note, that although the source is a RubyGem, we have to install the files manually under %\{_datadir}/%\{name}, %\{_bindir}, etc. to follow FHS and general packaging guidelines. If additional Fedora specific files (systemd `.service` files, configurations) are required, they SHOULD be

  

  * added via another `+%SOURCE+` tags

  

@@ -308,7 +360,7 @@ 

  

  === Testing With Different Ruby Implementations

  

- To run tests with different Ruby implementation such as JRuby, add `+BuildRequires: jruby+`. Then use Rubypick's interpreter switching:

+ To run tests with different Ruby implementation such as JRuby, add `BuildRequires: jruby`. Then use Rubypick's interpreter switching:

  

  ....

  ruby _jruby_ -Ilib -e 'Dir.glob "./test/test_*.rb", &method(:require)'

@@ -322,7 +374,7 @@ 

  

  ==== MiniTest / Test::UNIT

  

- MiniTest as well as Test::UNIT are shipped with Ruby. To use them, you need to use `+BuildRequires: rubygem-minitest+` or `+BuildRequires: rubygem-testunit+` respectively. To execute the test suite you can use something like:

+ MiniTest as well as Test::UNIT are shipped with Ruby. To use them, you need to use `BuildRequires: rubygem-minitest` or `BuildRequires: rubygem-testunit` respectively. To execute the test suite you can use something like:

  

  ....

  %check

@@ -333,7 +385,7 @@ 

  

  ==== RSpec

  

- To run tests using RSpec >= 3 you add `+BuildRequires: rubygem-rspec+` and use something like:

+ To run tests using RSpec >= 3 you add `BuildRequires: rubygem-rspec` and use something like:

  

  ....

  %check

@@ -342,7 +394,7 @@ 

  

  === Test suites not included in the package

  

- Sometimes you have to get the tests separately from upstream's gem package. As an example lets suppose you're packaging `+rubygem-delorean+`, version 1.2.0, which is hosted on Github. Tests are not included in the Gem itself, so you need to get them and adjust the specfile accordingly:

+ Sometimes you have to get the tests separately from upstream's gem package. As an example lets suppose you're packaging `rubygem-delorean`, version 1.2.0, which is hosted on Github. Tests are not included in the Gem itself, so you need to get them and adjust the specfile accordingly:

  

  ....

  # git clone https://github.com/bebanjo/delorean.git && cd delorean

@@ -1416,6 +1416,7 @@ 

  

  There are specific guidelines for handling tmpfiles.d configurations and directories (in /run and /run/lock): xref:Tmpfiles.d.adoc[Tmpfiles.d].

  

+ [#renaming-or-replacing-existing-packages]

  == Renaming/Replacing Existing Packages

  

  NOTE: FESCo has a https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required[package renaming policy] that should be followed when renaming an existing package.

Hard to judge without seeing the final result :/ but it can't be worse I guess ;)

BTW you have removed the TOC, will it be somewhere?

Hard to judge without seeing the final result :/ but it can't be worse I guess ;)

You can run make && make serve and observe result on https://localhost:8000/packaging-guidelines/Ruby/ :)

BTW you have removed the TOC, will it be somewhere?

would you like to have it?

Hard to judge without seeing the final result :/ but it can't be worse I guess ;)

You can run make && make serve and observe result on https://localhost:8000/packaging-guidelines/Ruby/ :)

Assuming I have all the dependencies installed, which I don't and I don't want to install them ...

BTW you have removed the TOC, will it be somewhere?

would you like to have it?

Well, it would be nice if the TOC was part of the global TOC/navigation on the left side. But as long as this is not the case, then yes, I want to have the TOC part of the document.

For the TOC, there is #804. Merging this without them to get other fixes.

rebased onto 727112e

9 months ago

Pull-Request has been merged by ignatenkobrain

9 months ago