From 9f5287b101f9f6a0f93e99367551214e106f8e3c Mon Sep 17 00:00:00 2001 From: Adam Samalik Date: Aug 14 2018 13:03:51 +0000 Subject: [PATCH 1/4] apply Flock feedback --- diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 6f0b906..6a99dd5 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -5,12 +5,11 @@ *** xref:architecture/consuming/dnf-behavior.adoc[DNF Behavior] * xref:making-modules.adoc[Making Modules] ** xref:making-modules/adding-new-modules.adoc[Adding New Modules] -** xref:making-modules/updating-modules.adoc[Updating Modules] -** xref:making-modules/inspecting-build-failures.adoc[Inspecting Build Failures] -** xref:making-modules/building-modules-locally.adoc[Building Modules Locally] +** xref:making-modules/updating-modules.adoc[Updating Existing Modules] ** xref:making-modules/defining-modules.adoc[Defining Modules in modulemd] ** xref:making-modules/managing-defaults.adoc[Managing Defaults] -** xref:making-modules/naming-guidelines.adoc[Naming Guidelines] +** xref:making-modules/inspecting-build-failures.adoc[Inspecting Build Failures] +** xref:making-modules/building-modules-locally.adoc[Building Modules Locally] * xref:using-modules.adoc[Using Modules] * xref:community.adoc[Community] ** xref:community/teams.adoc[Teams and Working Groups] diff --git a/modules/ROOT/pages/_partials/submit-module-build.adoc b/modules/ROOT/pages/_partials/submit-module-build.adoc index 4ca1c26..74ca816 100644 --- a/modules/ROOT/pages/_partials/submit-module-build.adoc +++ b/modules/ROOT/pages/_partials/submit-module-build.adoc @@ -1,23 +1,17 @@ -**Goal**: Get your packages built as a module. - -=== Steps: - -1. Submit a module build using fedpkg. -2. Make sure your build succeeded. - -=== Details: +With Modularity, you no longer build individual packages. Instead, you need to submit a module build. Module builds are triggered using `fedpkg` from whithin your dist-git repository. -For example, to submit a build of the `nodejs:10` module, run: - ---- -$ fedpkg clone modules/nodejs -$ cd nodejs -$ git checkout 10 +$ fedpkg clone modules/NAME +$ cd NAME +$ fedpkg switch-branch BRANCH $ fedpkg module-build ---- +* `NAME` — name of the module +* `BRANCH` — name of the stream branch of the module + NOTE: Please note the module build ID. You will need it to verify the build state. It also helps you in the next step. To watch the satate of your module build, run: @@ -26,4 +20,4 @@ To watch the satate of your module build, run: $ fedpkg module-build-watch BUILD_ID ---- -When the module is in a "ready" state, you can continue to the next step. \ No newline at end of file +When the module is in a "ready" state, the build has successfully completed. \ No newline at end of file diff --git a/modules/ROOT/pages/_partials/submit-module-update.adoc b/modules/ROOT/pages/_partials/submit-module-update.adoc index e0f04bd..26dbaf5 100644 --- a/modules/ROOT/pages/_partials/submit-module-update.adoc +++ b/modules/ROOT/pages/_partials/submit-module-update.adoc @@ -1,19 +1,10 @@ -**Goal**: Make your module go through Bodhi — the Fedora updates system. +To make your module available to users, submit submit as an update to https://bodhi.fedoraproject.org/[Fedora Bodhi]. Make sure you are logged in, and then click on Create / New Update at the top-right corner. Fill out the following fields: -=== Steps: - -1. Submit your module as an update in Bodhi. -2. Make sure your update has passed potential user testing. - -=== Details: - -To submit your module as an update, go to https://bodhi.fedoraproject.org/[Fedora Bodhi]. Make sure you are logged in, and then click on Create / New Update at the top-right corner. Fill out the following fields: - -* Candidate Builds: MODULE_BUILD_ID +* Candidate Builds: `MODULE_BUILD_ID` * Update notes: notes for the users * Final details: check what applies -One way of geting the MODULE_BUILD_ID is running the same command as in the previous step: +One way of geting the `MODULE_BUILD_ID` is running the same command as in the previous step: ---- $ fedpkg module-build-watch BUILD_ID diff --git a/modules/ROOT/pages/making-modules/adding-new-modules.adoc b/modules/ROOT/pages/making-modules/adding-new-modules.adoc index 67c40e7..03423d1 100644 --- a/modules/ROOT/pages/making-modules/adding-new-modules.adoc +++ b/modules/ROOT/pages/making-modules/adding-new-modules.adoc @@ -1,76 +1,116 @@ = Adding new modules to Fedora -This page will guide you through the whole process of adding a new module to Fedora. There is also an official https://fedoraproject.org/wiki/Modularity/Adding_New_Modules_and_Managing_Defaults[process for adding new modules] which will give you a summary of the major steps you need to undergo, and is the authoritative point of truth. +This page will guide you through the whole process of adding a new module to Fedora: -== Step 1: Get your RPM packages in place +1. **<>** — To `dist-git/rpms` using stream branches. +2. **<>** — To `dist-git/modules` using stream branches. +3. **<>** — Module is built as a unit. No individual package builds are done. +4. **<>** — Submitting a Bodhi update. -**Goal**: Get your RPM package(s) pushed into the Fedora Distribution Git (dist-git). +== RPM Sources -=== Workflow Summary: +For each package in your module, you need to have a Fedora Distribution Git (dist-git) **repository** under `dist-git/rpms` with apropriate **stream branch**. New packages need to go through a **package review**. -1. Create your new RPM package. -2. Submit your package for Fedora Review. (only for new packages) -3. Request a new repository and/or a branch in dist-git. -4. Push your package sources into dist-git. +=== Repositories and Stream Branches — New packages -=== Details: +The https://fedoraproject.org/wiki/Package_Review_Process#Contributor[Fedora Package Review Process] covers all the steps you need to take, except for stream branches. For that, please continue below to Existing packages. -When creating your new http://rpm.org/[RPM package], please make sure it complies with the https://fedoraproject.org/wiki/Packaging:Guidelines[Fedora Packaging Guidelines]. +=== Repositories and Stream Branches — Existing packages -NOTE: If you adding a new branch to an existing package, you can skip the review part and proceed to requesting a new branch. +Requesting new stream branches for existing packages is done with `fedpkg`, and it doesn't require a package review. -To learn about the Fedora review, requesting repositories and branches, and pushing sources to dist-git, please see the https://fedoraproject.org/wiki/Package_Review_Process#Contributor[Fedora Package Review Process] +// I have commented the following section out, since it was more confusing than helpful. +//// +You have two options: -== Step 2: Get your module definition in place +**Option 1: Your module will only contain this package, or this package is the main one in the module.** In this case, you can request both, the package stream branch and the module repository + its stream branch in one step: -**Goal**: Get your module definition pushed into the Fedora Distribution Git (dist-git). +---- +$ fedpkg --module-name=NAME request-branch BRANCH --sl rawhide:2020-12-01 +---- -=== Steps: +* `NAME` — name of the package and the module +* `BRANCH` — name of the stream branch of the package and the module +* `rawhide:2020-12-01` — expected end of life, must end with either `12-01` or `06-01` -1. Write a modulemd. -2. Request a new repository and/or a branch in dist-git. -3. Push your modulemd into dist-git. +**Option 2: This package is an additional one to a module.** In this case, only request the stream branch for the package: +//// -=== Details: +---- +$ fedpkg --module-name=NAME request-branch BRANCH --no-auto-module --sl rawhide:2020-12-01 +---- -Writing a modulemd is covered in detail in the xref:making-modules/defining-modules.adoc[Defining Modules in modulemd] section. +* `NAME` — name of the package +* `BRANCH` — name of the stream branch of the package +* `rawhide:2020-12-01` — expected end of life, must end with either `12-01` or `06-01` + +=== Importing the PRM sources into dist-git + +The last thing to do is to import the RPM sources into dist-git. Remember to switch to the correct stream branch after cloning your repository: + +---- +$ fedpkg clone rpms/NAME +$ cd NAME +$ fedpkg switch-branch BRANCH +$ fedpkg import PATH_TO_SRPM +$ git commit -m "your message here" +$ git push +---- + +* `NAME` — name of the package +* `BRANCH` — name of the stream branch of the package +* `PATH_TO_SRPM` — local path to the SRPM package -NOTE: Running the following `fedpkg` commands requires a ticket to be created at https://pagure.io/settings/token/new and saved in `\~/.config/rpkg/fedpkg.conf` +== Module Definition -WARNING: Please remember that the name of your module will be the name of your repository. The same way, the stream name of your module will be the name of the branch. Both of these will be visible to users. +For your module definition, you also need to have a dist-git **repository**, this time under `dist-git/modules`, with apropriate **stream branch**. -To request a new repository in dist-git, for example for a `nodejs` module, run: +=== Repositories and Stream Branches — New modules + +To request a new module repository in dist-git run: ---- -$ fedpkg --module-name modules/nodejs request-repo --exception +$ fedpkg --module-name modules/NAME request-repo --exception +$ fedpkg --module-name modules/NAME request-branch BRANCH ---- -And to request a new branch, for example for a `nodejs:10` module, run: +* `NAME` — name of the module +* `BRANCH` — name of the stream branch of the module + +=== Repositories and Stream Branches — Existing modules + +to request a new stream branch, run: ---- -$ fedpkg --module-name modules/nodejs request-branch 10 +$ fedpkg --module-name modules/NAME request-branch BRANCH ---- -To push your modulemd into dist-git, clone the dist-git repository, change to the correct branch, add your modulemd, and push it as you would in git. +* `NAME` — name of the module +* `BRANCH` — name of the stream branch of the module + +=== Write and push the modulemd -NOTE: Please make sure that the name of your modulemd file matches the name of the dist-git repository. +Writing a modulemd is covered in detail in the xref:making-modules/defining-modules.adoc[Defining Modules in modulemd] section. -For example, to push the `nodejs:10` module definition, run: +NOTE: The name of the modulemd must match the name of the repository. Remember to replace every `NAME` in the following example. ---- -$ fedpkg clone modules/nodejs -$ cd nodejs -$ git checkout 10 -$ vim nodejs.yaml -$ git add nodejs.yaml +$ fedpkg clone modules/NAME +$ cd NAME +$ fedpkg switch-branch BRANCH +$ vim NAME.yaml +$ git add NAME.yaml $ git commit -m "add the initial modulemd" $ git push ---- -== Step 3: Build your module +* `NAME` — name of the module +* `BRANCH` — name of the stream branch of the module + +== Module Build include::{partialsdir}/submit-module-build.adoc[] -== Step 4: Make your module available to users +== Publishing the Module include::{partialsdir}/submit-module-update.adoc[] \ No newline at end of file diff --git a/modules/ROOT/pages/making-modules/defining-modules.adoc b/modules/ROOT/pages/making-modules/defining-modules.adoc index aa3c946..5072263 100644 --- a/modules/ROOT/pages/making-modules/defining-modules.adoc +++ b/modules/ROOT/pages/making-modules/defining-modules.adoc @@ -1,12 +1,80 @@ = Defining modules in modulemd -Modules are defined using a https://pagure.io/modulemd[modulemd file]. The definition includes the summary and description, list of source RPM packages, build information i.e. buildroot, and usage information i.e. installation profiles or licenses. +Simply put, a **https://pagure.io/modulemd[modulemd] is a file that defines what packages get build for what releases**. It includes a summary and a description, a list of source RPM packages, build information i.e. build order and macros, and usage information i.e. installation profiles and licenses. -This page will help you with writing a module definition from scratch. Even though this page is meant to be up-to-date, please make sure your module complies with the https://fedoraproject.org/wiki/Module:Guidelines[Fedora Packaging Guidelines for Modules] as it is the authoritative point of truth. +== A typical modulemd example -This page includes the <>, the <>, examples of <>, and a <>. +A typical modulemd file looks similar to the following examples. Read on for more details about each part of the modulemd file. -== Common definitions +Feel free to copy/paste this example when creating your new module. + +[source,yaml] +---- +document: modulemd +version: 2 +data: + # === Information about this module ================================== + # (Can be copied from the main RPM package, but doesn't need to be) + summary: An example module + description: >- + A module for the demonstration of the metadata format. Also, + the obligatory lorem ipsum dolor sit amet goes right here. + + # === License of this modulemd file ================================== + # (Package licenses will be added automatically by the build system) + license: + module: + - MIT + + # === Modular dependencies =========================================== + # (For which Fedora releases to build?) + dependencies: + - buildrequires: + platform: [] # <- Build for all Fedora releases + requires: + platform: [] # <- Run on all Fedora releases + + # === Module API (optional, but encouraged) ========================== + # (Which packages are API-stable?) + api: + rpms: + - package-one # <- Binary RPM package name + - package-one-extras # <- Binary RPM package name + - package-one-cli # <- Binary RPM package name + - package-one-devel # <- Binary RPM package name + - package-two # <- Binary RPM package name + + # === Installation profiles (optional, but encouraged) =============== + # (Helping users with installation by providing pre-defined groups) + profiles: + default: # <- Name of the profile + description: A standard installation. + rpms: + - package-one # <- Binary RPM package name + - package-one-extras # <- Binary RPM package name + - package-two # <- Binary RPM package name + cli: # <- Name of the profile + description: A command-line client. + rpms: + - package-one-cli # <- Binary RPM package name + + # === Packages in this module ======================================== + # (Referenced by their dist-git repo name + branch name) + components: + rpms: + first-package: # <- Source RPM package name + ref: 3.0 # <- Branch name in dist-git + rationale: Provides the core functionality. + second-package: # <- Source RPM package name + ref: latest # <- Branch name in dist-git + rationale: Web UI for the first-package. +---- + +== Common modulemd definitions + +These are the common parts of a modulemd file, used in the example above. Advanced definitions, including a complex example of Module Stream Expansion (MSE), are towards the end of this page. + +=== Document header Every modulemd starts with these three lines: @@ -20,9 +88,9 @@ data: <1> All the following definitions go here, under _data_. -=== Information about your module +=== Information about this module -Tell users what this module represents by writing a summary and a description, and how can they use it by specifying a license. +Tell users what this module represents by writing a summary and a description. [source,yaml] ---- @@ -30,42 +98,28 @@ Tell users what this module represents by writing a summary and a description, a description: >- <1> A module for the demonstration of the metadata format. Also, the obligatory lorem ipsum dolor sit amet goes right here. - license: - module: - - MIT <2> ---- <1> The `>-` means new line in YAML. Useful for longer blocks of text, such as the description! -<2> A license for this modulemd file. Fedora content, such as SPEC files or patches not included upstream, uses the MIT license by default, unless the component packager declares otherwise. +=== License of this modulemd file -=== List the packages - -To make your module useful, include some RPM packages in it. List all source RPM packages this module should include. +This is a license of this very modulemd file and it doesn't need to be modified. +The buildsystem adds licenses of all packages to this list automatically. [source,yaml] ---- - components: - rpms: - first-package: <1> - rationale: Provides the core functionality. <2> - ref: 3.0 <3> - second-package: - rationale: Web UI for the first-package. - ref: stable - ... <4> + license: + module: + - MIT <1> ---- -<1> Name of the package — maps to a DistGit repository name. +<1> A license for this modulemd file. Fedora content, such as SPEC files or patches not included upstream, uses the MIT license by default, unless the component packager declares otherwise. -<2> The reason why is this package here. Mostly for humans. +=== Modular dependencies -<3> DistGit branch, tag, or a commit — so the right version of the package gets included. - -<4> List as many packages as you need. - -=== For which releases? +Simply put: For which Fedora releases to build? To build your module for all Fedora releases that are actively maintained, use the following definition. For anything more than this, such as building against other modules or requiring other modules during runtime, please see the Advanced section below. @@ -78,7 +132,7 @@ To build your module for all Fedora releases that are actively maintained, use t platform: [] ---- -=== Help users install it (optional, but encouraged) +=== Installation profiles (optional, but encouraged) To help users install your module, define installation profiles. These profiles represent a specific use case of your module. Most modules have at least a default profile. But you can specify more. For example, a database module can have a server and a client profile. @@ -106,7 +160,7 @@ To help users install your module, define installation profiles. These profiles <4> List as many profiles as you need. -=== Public API (optional, but encouraged) +=== Module API (optional, but encouraged) List all binary RPM packages in your module that you consider to be the main stable feature of the module. Other (unlisted) packages should be considered unsupported, or an implementation detail. @@ -121,6 +175,31 @@ List all binary RPM packages in your module that you consider to be the main sta - package-two ---- +=== Packages in this module + +List all source SRPM packages this module should include, referenced them by their dist-git repo name + branch name. + +[source,yaml] +---- + components: + rpms: + first-package: <1> + rationale: Provides the core functionality. <2> + ref: 3.0 <3> + second-package: + rationale: Web UI for the first-package. + ref: latest + ... <4> +---- + +<1> Name of the package — maps to a DistGit repository name. + +<2> The reason why is this package here. Mostly for humans. + +<3> DistGit branch, tag, or a commit — so the right version of the package gets included. + +<4> List as many packages as you need. + == Advanced definitions === References to the upstream (optional) @@ -159,7 +238,7 @@ In this specific example, `first-package` gets built first, and `second-package` buildorder: 0 <1> second-package: rationale: Web UI for the first-package. - ref: stable + ref: latest buildorder: 10 <1> ---- @@ -187,10 +266,7 @@ modules can be * built agains one or more streams of the same module * work with one or more streams of another module - -==== Building for a specific Fedora release(s) only - -Building **only for Fedora 28**: +**Building only for Fedora 28**: [source,yaml] ---- @@ -201,7 +277,7 @@ Building **only for Fedora 28**: platform: [f28] ---- -Building **for everything else than Fedora 28**: +**Building for everything else than Fedora 28**: [source,yaml] ---- @@ -212,7 +288,7 @@ Building **for everything else than Fedora 28**: platform: [-f28] ---- -Building **only for Fedora 28 and Fedora 29**: +**Building only for Fedora 28 and Fedora 29**: [source,yaml] ---- @@ -223,7 +299,7 @@ Building **only for Fedora 28 and Fedora 29**: platform: [f28, f29] ---- -==== Depending on other modules +**Building against other modules:**: Your module can also depend on another modules. Specific streams can be referenced the same way as above in "Building for a specific Fedora release(s) only". @@ -238,7 +314,7 @@ Your module can also depend on another modules. Specific streams can be referenc nodejs: [] ---- -==== Complex dependencies +**A complex example:** Simple things should simple, complex things should be possible. Let's say my module requires `nodejs` during build and run time. It also requires `build-tools` only during build. To make it even more complex, it also requires a specific stream of a `pizza-module` during build and run time, but only on Fedora 27. @@ -266,7 +342,7 @@ Simple things should simple, complex things should be possible. Let's say my mod For even more complex scenarios, please study the https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml[modulemd specification]. -=== Binary packages to exclude (optional) +=== 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`. @@ -308,7 +384,7 @@ data: ref: 3.0 second-package: rationale: Web UI for the first-package. - ref: stable + ref: latest ---- === Including profiles and API (recommended) @@ -357,7 +433,7 @@ data: ref: 3.0 second-package: rationale: Web UI for the first-package. - ref: stable + ref: latest ---- === Bonus: Converting modulemd v1 to v2 diff --git a/modules/ROOT/pages/making-modules/updating-modules.adoc b/modules/ROOT/pages/making-modules/updating-modules.adoc index c1f516d..22cf9c6 100644 --- a/modules/ROOT/pages/making-modules/updating-modules.adoc +++ b/modules/ROOT/pages/making-modules/updating-modules.adoc @@ -2,45 +2,39 @@ This page will guide you through the process of updating an existing module. -== Step 1: Update your RPM packages +1. **<>** — Pushing new sources. +2. **<>** — Pushing a new version of the modulemd. +3. **<>** — Module is built as a unit. No individual package builds are done. +4. **<>** — Submitting a Bodhi update. -**Goal**: Get updates for your PRM packages pushed into the Fedora Distribution Git (dist-git). +== Updating RPM Packages -=== Workflow Summary: - -1. Make changes to your RPM package sources. -2. Push your RPM package sources to dist-git. - -=== Details: +Update your RPM packages the same way you would do traditionally, exept submitting individual package builds. Useful resources: * https://fedoraproject.org/wiki/Packaging:Guidelines[Fedora Packaging Guidelines] * https://fedoraproject.org/wiki/Package_maintenance_guide[Fedora Package Maintenance Guide] -== Step 2: Bump the module version - -**Goal**: Get your module definition describing the new version pushed into the Fedora Distribution Git (dist-git). This needs to be done even when the modulemd doesn't change. - -=== Workflow Summary: +== Updaging the Module -1. Push an empty commit to your module dist-git repository. - -=== Details: - -The version of your module is taken from the last commit timestamp. Therefore, in order to submit a new module build, you need to make a new commit. To push an empty commit to your modulemd, run: +Even when you don't need to make any changes to the modulemd, you still need to push a new commit to build a new version. ---- -$ fedpkg clone modules/nodejs -$ cd nodejs +$ fedpkg clone modules/NAME +$ cd NAME +$ fedpkg switch-branch BRANCH $ git commit --allow-empty -m "update" -$ git push +git push ---- -== Step 3: Build your module +* `NAME` — name of the module +* `BRANCH` — name of the stream branch of the module + +== Module Build include::{partialsdir}/submit-module-build.adoc[] -== Step 4: Make your module available to users +== Publishing the Module include::{partialsdir}/submit-module-update.adoc[] \ No newline at end of file From 035d5dbe1b41843e70a492021ed0eec40c1f3643 Mon Sep 17 00:00:00 2001 From: Adam Samalik Date: Aug 14 2018 13:21:50 +0000 Subject: [PATCH 2/4] one command for pkg + module repo --- diff --git a/modules/ROOT/pages/making-modules/adding-new-modules.adoc b/modules/ROOT/pages/making-modules/adding-new-modules.adoc index 03423d1..64452bf 100644 --- a/modules/ROOT/pages/making-modules/adding-new-modules.adoc +++ b/modules/ROOT/pages/making-modules/adding-new-modules.adoc @@ -16,33 +16,25 @@ For each package in your module, you need to have a Fedora Distribution Git (dis The https://fedoraproject.org/wiki/Package_Review_Process#Contributor[Fedora Package Review Process] covers all the steps you need to take, except for stream branches. For that, please continue below to Existing packages. === Repositories and Stream Branches — Existing packages - Requesting new stream branches for existing packages is done with `fedpkg`, and it doesn't require a package review. -// I have commented the following section out, since it was more confusing than helpful. -//// -You have two options: - -**Option 1: Your module will only contain this package, or this package is the main one in the module.** In this case, you can request both, the package stream branch and the module repository + its stream branch in one step: +To create a new branch for a package that shares a name with the module (e.g. "postgresql"), run the following command which will create the package stream branch as well as the module and its stream branch together: ---- $ fedpkg --module-name=NAME request-branch BRANCH --sl rawhide:2020-12-01 ---- - * `NAME` — name of the package and the module * `BRANCH` — name of the stream branch of the package and the module * `rawhide:2020-12-01` — expected end of life, must end with either `12-01` or `06-01` -**Option 2: This package is an additional one to a module.** In this case, only request the stream branch for the package: -//// +If this package does not share a name with the module (such as for dependencies), then only request the stream branch for this package: ---- $ fedpkg --module-name=NAME request-branch BRANCH --no-auto-module --sl rawhide:2020-12-01 ---- +* `--no-auto-module` — Skip the creation of a module of the same name -* `NAME` — name of the package -* `BRANCH` — name of the stream branch of the package -* `rawhide:2020-12-01` — expected end of life, must end with either `12-01` or `06-01` +Creation of the module and its stream branches separately will be covered later. === Importing the PRM sources into dist-git From 65e7a50357b2e63d3d9cd237270b817065768d86 Mon Sep 17 00:00:00 2001 From: Adam Samalik Date: Aug 14 2018 13:31:27 +0000 Subject: [PATCH 3/4] fix the fedpkg request-* commands --- diff --git a/modules/ROOT/pages/making-modules/adding-new-modules.adoc b/modules/ROOT/pages/making-modules/adding-new-modules.adoc index 64452bf..8fdd3ad 100644 --- a/modules/ROOT/pages/making-modules/adding-new-modules.adoc +++ b/modules/ROOT/pages/making-modules/adding-new-modules.adoc @@ -21,7 +21,7 @@ Requesting new stream branches for existing packages is done with `fedpkg`, and To create a new branch for a package that shares a name with the module (e.g. "postgresql"), run the following command which will create the package stream branch as well as the module and its stream branch together: ---- -$ fedpkg --module-name=NAME request-branch BRANCH --sl rawhide:2020-12-01 +$ fedpkg request-branch --repo=NAME --sl rawhide:2020-12-01 BRANCH ---- * `NAME` — name of the package and the module * `BRANCH` — name of the stream branch of the package and the module @@ -30,7 +30,7 @@ $ fedpkg --module-name=NAME request-branch BRANCH --sl rawhide:2020-12-01 If this package does not share a name with the module (such as for dependencies), then only request the stream branch for this package: ---- -$ fedpkg --module-name=NAME request-branch BRANCH --no-auto-module --sl rawhide:2020-12-01 +$ fedpkg request-branch --repo=NAME --sl rawhide:2020-12-01 --no-auto-module BRANCH ---- * `--no-auto-module` — Skip the creation of a module of the same name @@ -62,8 +62,8 @@ For your module definition, you also need to have a dist-git **repository**, thi To request a new module repository in dist-git run: ---- -$ fedpkg --module-name modules/NAME request-repo --exception -$ fedpkg --module-name modules/NAME request-branch BRANCH +$ fedpkg request-repo --namespace modules --exception NAME +$ fedpkg request-branch --namespace modules --repo NAME BRANCH ---- * `NAME` — name of the module @@ -74,7 +74,7 @@ $ fedpkg --module-name modules/NAME request-branch BRANCH to request a new stream branch, run: ---- -$ fedpkg --module-name modules/NAME request-branch BRANCH +$ fedpkg request-branch --namespace modules --repo NAME BRANCH ---- * `NAME` — name of the module From 2727bdd1d0e83a2bf73212f71be850f05e21e145 Mon Sep 17 00:00:00 2001 From: Adam Samalik Date: Aug 14 2018 15:11:40 +0000 Subject: [PATCH 4/4] apply PR feedback --- diff --git a/modules/ROOT/pages/_partials/submit-module-build.adoc b/modules/ROOT/pages/_partials/submit-module-build.adoc index 74ca816..a88a46d 100644 --- a/modules/ROOT/pages/_partials/submit-module-build.adoc +++ b/modules/ROOT/pages/_partials/submit-module-build.adoc @@ -14,7 +14,7 @@ $ fedpkg module-build NOTE: Please note the module build ID. You will need it to verify the build state. It also helps you in the next step. -To watch the satate of your module build, run: +To watch the state of your module build, run: ---- $ fedpkg module-build-watch BUILD_ID diff --git a/modules/ROOT/pages/_partials/submit-module-update.adoc b/modules/ROOT/pages/_partials/submit-module-update.adoc index 26dbaf5..445898a 100644 --- a/modules/ROOT/pages/_partials/submit-module-update.adoc +++ b/modules/ROOT/pages/_partials/submit-module-update.adoc @@ -7,7 +7,7 @@ To make your module available to users, submit submit as an update to https://bo One way of geting the `MODULE_BUILD_ID` is running the same command as in the previous step: ---- -$ fedpkg module-build-watch BUILD_ID +$ fedpkg module-build-info BUILD_ID ---- and changing the "koji tag" value in the following way: diff --git a/modules/ROOT/pages/making-modules/adding-new-modules.adoc b/modules/ROOT/pages/making-modules/adding-new-modules.adoc index 8fdd3ad..1c3f284 100644 --- a/modules/ROOT/pages/making-modules/adding-new-modules.adoc +++ b/modules/ROOT/pages/making-modules/adding-new-modules.adoc @@ -36,22 +36,10 @@ $ fedpkg request-branch --repo=NAME --sl rawhide:2020-12-01 --no-auto-module BRA Creation of the module and its stream branches separately will be covered later. -=== Importing the PRM sources into dist-git +=== Importing the RPM sources into dist-git -The last thing to do is to import the RPM sources into dist-git. Remember to switch to the correct stream branch after cloning your repository: - ----- -$ fedpkg clone rpms/NAME -$ cd NAME -$ fedpkg switch-branch BRANCH -$ fedpkg import PATH_TO_SRPM -$ git commit -m "your message here" -$ git push ----- - -* `NAME` — name of the package -* `BRANCH` — name of the stream branch of the package -* `PATH_TO_SRPM` — local path to the SRPM package +The last thing to do is to import the RPM sources into dist-git. Please refer to the https://fedoraproject.org/wiki/New_package_process_for_existing_contributors[New package process for existing contributors +] for the complete steps. == Module Definition diff --git a/modules/ROOT/pages/making-modules/defining-modules.adoc b/modules/ROOT/pages/making-modules/defining-modules.adoc index 5072263..a9d344c 100644 --- a/modules/ROOT/pages/making-modules/defining-modules.adoc +++ b/modules/ROOT/pages/making-modules/defining-modules.adoc @@ -1,6 +1,6 @@ = Defining modules in modulemd -Simply put, a **https://pagure.io/modulemd[modulemd] is a file that defines what packages get build for what releases**. It includes a summary and a description, a list of source RPM packages, build information i.e. build order and macros, and usage information i.e. installation profiles and licenses. +Simply put, a **https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml[modulemd] is a file that defines what packages get build for what releases**. It includes a summary and a description, a list of source RPM packages, build information i.e. build order and macros, and usage information i.e. installation profiles and licenses. == A typical modulemd example @@ -434,12 +434,4 @@ data: second-package: rationale: Web UI for the first-package. ref: latest ----- - -=== Bonus: Converting modulemd v1 to v2 - -This video walks through the differences between the legacy modulemd v1 and the current modulemd v2. - -++++ - -++++ \ No newline at end of file +---- \ No newline at end of file