#87 Added information about module filters
Merged 3 years ago by mcurlej. Opened 3 years ago by mcurlej.
fedora-docs/ mcurlej/modularity filtering_modules  into  master

@@ -43,6 +43,12 @@ 

              - package-one-cli    # <- Binary RPM package name

              - package-one-devel  # <- Binary RPM package name

              - package-two        # <- Binary RPM package name

+ 

+     # === Package filtering ==============================================

+     # (Which packages should not be included into the resulting module)

+     filter:

+         rpms:

+             - subpackage-one     # <- Binary RPM package name

      

      # === Installation profiles (optional, but encouraged) ===============

      # (Helping users with installation by providing predefined groups)
@@ -341,10 +347,12 @@ 

  

  For even more complex scenarios, please study the https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml[modulemd specification].

  

+ === Filtered Packages (optional, defaults to no filters)

  

- === Excluding binary packages (optional)

- 

- One source RPM package might produce multiple binary RPM packages. If you don't want to include some binary packages, list them under `filter`.

+ The build process of a RPM packages can result in a subpackages which complement the build of the package (docs, additional build requires etc.). One source RPM package might produce multiple binary 

+ RPM packages. Those subpackages are not always desired to be shipped with the Module. Modules enable you to filter out those undesirable packages with the `filter` build option. After the build is finished the filtered packages will be not included in the `artifacts` property in the result modulemd 

+ yaml file. The `artifacts` property is added by the build system post build. For an example please 

+ refer to the https://github.com/fedora-modularity/libmodulemd/tree/main/yaml_specs[modulemd spec files].

  

  Filtered RPMs are still available to use as build dependencies in subsequent stages of the module build, but are not included in the composed repository for users.

  

Would be nice to hard-wrap lines at some reasonable length (120 characters?), otherwise it unreadable in diffs.

But otherwise, it looks good to me, except for some little issues such as

... of the package. (docs, additional build requires etc.) Those subpackages

The interpunction IMHO isn't correct here. I think it should be "... of the package (docs, additional build requires etc). Those subpackages ..."

The build process of a RPM packages

There shouldn't be "a" before plural

rebased onto 17fc9164a5074d40ac03f34809ee226bbf926147

3 years ago

rebased onto 7b19941

3 years ago

Pull-Request has been merged by mcurlej

3 years ago