| Message ID | 20230214144927.80982-1-michael.opdenacker@bootlin.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] dev-manual: stop advising to produce patches with Quilt | expand |
Hi Michael, On 2/14/23 15:49, Michael Opdenacker via lists.yoctoproject.org wrote: > From: Michael Opdenacker <michael.opdenacker@bootlin.com> > > Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> > > --- > > Who still wants to produce patches with Quilt instead of Git? > Who still wants to accept patches which are not generated by Git > or a modern source control system? > Well... Quilt is the tool used to patch most recipes by bitbake AFAIR :) c.f. PATCHTOOL in meta/conf/bitbake.conf. Since they probably have a different conflict resolution, it might still be a good idea to explain how to create patches with quilt? or do we expect to just say "set PATCHTOOL = "git" in your recipe if the patch doesn't apply" ? Note that the only time I had to use git PATCHTOOL was for patches where there was some binary in there since quilt doesn't support this. Cheers, Quentin
Hi Quentin Thanks for the review! On 14.02.23 at 15:59, Quentin Schulz wrote: > Hi Michael, > > On 2/14/23 15:49, Michael Opdenacker via lists.yoctoproject.org wrote: >> From: Michael Opdenacker <michael.opdenacker@bootlin.com> >> >> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> >> >> --- >> >> Who still wants to produce patches with Quilt instead of Git? >> Who still wants to accept patches which are not generated by Git >> or a modern source control system? >> > > Well... Quilt is the tool used to patch most recipes by bitbake AFAIR > :) c.f. PATCHTOOL in meta/conf/bitbake.conf. Since they probably have > a different conflict resolution, it might still be a good idea to > explain how to create patches with quilt? or do we expect to just say > "set PATCHTOOL = "git" in your recipe if the patch doesn't apply" ? That's right this is still the default PATCHTOOL. However, how likely are we to have issues with git patches that don't apply with quilt, as less than 1% of the patches currently in use were produced by quilt. What I mean is that it feels weird to recommend a solution that almost nobody uses any more to create patches for recipes. Cheers Michael.
On Tue, 2023-02-14 at 15:59 +0100, Quentin Schulz via lists.yoctoproject.org wrote: > Hi Michael, > > On 2/14/23 15:49, Michael Opdenacker via lists.yoctoproject.org wrote: > > From: Michael Opdenacker <michael.opdenacker@bootlin.com> > > > > Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> > > > > --- > > > > Who still wants to produce patches with Quilt instead of Git? > > Who still wants to accept patches which are not generated by Git > > or a modern source control system? > > > > Well... Quilt is the tool used to patch most recipes by bitbake AFAIR :) > c.f. PATCHTOOL in meta/conf/bitbake.conf. Since they probably have a > different conflict resolution, it might still be a good idea to explain > how to create patches with quilt? or do we expect to just say "set > PATCHTOOL = "git" in your recipe if the patch doesn't apply" ? > > Note that the only time I had to use git PATCHTOOL was for patches where > there was some binary in there since quilt doesn't support this. I think a lot depends on the underlying recipe. If it uses a tarball, quilt will be there, git won't be setup. If the underlying recipe uses git, creating patches with it can be easier. Personally, I still do use quilt as it is muscle memory. With git you have issues that the indexes can be out of sync due to patches or autoreconf. I think we should document the git workflow and then let the user choose which direction to go. We should make the pitfalls clear too (index not in sync, no git metadata on a tarball etc.) Cheers, Richard
On Tue, 2023-02-14 at 15:49 +0100, Michael Opdenacker via lists.yoctoproject.org wrote: > From: Michael Opdenacker <michael.opdenacker@bootlin.com> > > Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> > > --- > > Who still wants to produce patches with Quilt instead of Git? > Who still wants to accept patches which are not generated by Git > or a modern source control system? > > Today: > - 1012 patches in Poky were created using Git > - 4 patches were created using Quilt > > If this patch is acceptable, I'll also update > dev-manual/debugging.rst so that it gives an example > based on git, to create a patch for a package to fix. > --- > documentation/dev-manual/debugging.rst | 3 - > documentation/dev-manual/index.rst | 1 - > documentation/dev-manual/quilt.rst | 89 -------------------------- > 3 files changed, 93 deletions(-) > delete mode 100644 documentation/dev-manual/quilt.rst I am 100% against deleting the information on quilt. We do use it in the builds for applying patches and it should therefore be covered in the manual. I am fine with documenting git and giving the user a choice on which tool to use to generate patches. Cheers, Richard
On 15.02.23 at 11:36, Richard Purdie wrote: > On Tue, 2023-02-14 at 15:49 +0100, Michael Opdenacker via > lists.yoctoproject.org wrote: >> From: Michael Opdenacker <michael.opdenacker@bootlin.com> >> >> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> >> >> --- >> >> Who still wants to produce patches with Quilt instead of Git? >> Who still wants to accept patches which are not generated by Git >> or a modern source control system? >> >> Today: >> - 1012 patches in Poky were created using Git >> - 4 patches were created using Quilt >> >> If this patch is acceptable, I'll also update >> dev-manual/debugging.rst so that it gives an example >> based on git, to create a patch for a package to fix. >> --- >> documentation/dev-manual/debugging.rst | 3 - >> documentation/dev-manual/index.rst | 1 - >> documentation/dev-manual/quilt.rst | 89 -------------------------- >> 3 files changed, 93 deletions(-) >> delete mode 100644 documentation/dev-manual/quilt.rst > I am 100% against deleting the information on quilt. We do use it in > the builds for applying patches and it should therefore be covered in > the manual. > > I am fine with documenting git and giving the user a choice on which > tool to use to generate patches. Thanks for the strong points. I'll see what I can do, but I'm not sure I want to complicate the explanations too much. Thanks again Michael.
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index 9fb159eae6..e36d5a8fc1 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst @@ -820,9 +820,6 @@ to patch the ``Makefile.am`` file, which is generated from $ quilt add Makefile.am File Makefile.am added to patch patches/parallelmake.patch -For more information on using Quilt, see the -":ref:`dev-manual/quilt:using quilt in your workflow`" section. - At this point you need to make the edits to ``Makefile.am`` to add the missing dependency. For our example, you have to add the following line to the file:: diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst index b0bb5576ad..affea1cf46 100644 --- a/documentation/dev-manual/index.rst +++ b/documentation/dev-manual/index.rst @@ -18,7 +18,6 @@ Yocto Project Development Tasks Manual new-machine upgrading-recipes temporary-source-code - quilt.rst development-shell python-development-shell building diff --git a/documentation/dev-manual/quilt.rst b/documentation/dev-manual/quilt.rst deleted file mode 100644 index 59240705ad..0000000000 --- a/documentation/dev-manual/quilt.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. SPDX-License-Identifier: CC-BY-SA-2.0-UK - -Using Quilt in Your Workflow -**************************** - -`Quilt <https://savannah.nongnu.org/projects/quilt>`__ is a powerful tool -that allows you to capture source code changes without having a clean -source tree. This section outlines the typical workflow you can use to -modify source code, test changes, and then preserve the changes in the -form of a patch all using Quilt. - -.. note:: - - With regard to preserving changes to source files, if you clean a - recipe or have :ref:`ref-classes-rm-work` enabled, the - :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>` - as described in the Yocto Project Application Development and the - Extensible Software Development Kit (eSDK) manual is a safer - development flow than the flow that uses Quilt. - -Follow these general steps: - -#. *Find the Source Code:* Temporary source code used by the - OpenEmbedded build system is kept in the :term:`Build Directory`. See the - ":ref:`dev-manual/temporary-source-code:finding temporary source code`" section to - learn how to locate the directory that has the temporary source code for a - particular package. - -#. *Change Your Working Directory:* You need to be in the directory that - has the temporary source code. That directory is defined by the - :term:`S` variable. - -#. *Create a New Patch:* Before modifying source code, you need to - create a new patch. To create a new patch file, use ``quilt new`` as - below:: - - $ quilt new my_changes.patch - -#. *Notify Quilt and Add Files:* After creating the patch, you need to - notify Quilt about the files you plan to edit. You notify Quilt by - adding the files to the patch you just created:: - - $ quilt add file1.c file2.c file3.c - -#. *Edit the Files:* Make your changes in the source code to the files - you added to the patch. - -#. *Test Your Changes:* Once you have modified the source code, the - easiest way to test your changes is by calling the :ref:`ref-tasks-compile` - task as shown in the following example:: - - $ bitbake -c compile -f package - - The ``-f`` or ``--force`` option forces the specified task to - execute. If you find problems with your code, you can just keep - editing and re-testing iteratively until things work as expected. - - .. note:: - - All the modifications you make to the temporary source code disappear - once you run the :ref:`ref-tasks-clean` or :ref:`ref-tasks-cleanall` - tasks using BitBake (i.e. ``bitbake -c clean package`` and - ``bitbake -c cleanall package``). Modifications will also disappear if - you use the :ref:`ref-classes-rm-work` feature as described in - the ":ref:`dev-manual/disk-space:conserving disk space during builds`" - section. - -#. *Generate the Patch:* Once your changes work as expected, you need to - use Quilt to generate the final patch that contains all your - modifications:: - - $ quilt refresh - - At this point, the - ``my_changes.patch`` file has all your edits made to the ``file1.c``, - ``file2.c``, and ``file3.c`` files. - - You can find the resulting patch file in the ``patches/`` - subdirectory of the source (:term:`S`) directory. - -#. *Copy the Patch File:* For simplicity, copy the patch file into a - directory named ``files``, which you can create in the same directory - that holds the recipe (``.bb``) file or the append (``.bbappend``) - file. Placing the patch here guarantees that the OpenEmbedded build - system will find the patch. Next, add the patch into the :term:`SRC_URI` - of the recipe. Here is an example:: - - SRC_URI += "file://my_changes.patch" -