I am not maintaining packages in Fedora. But my work is related to building them for AArch64 architecture. And this means editing patches and/or adding new ones…

When I was doing AArch64 bootstrap in OpenEmbedded it was easy. Altering Debian/Ubuntu packages was also simple task. Why? Because in both situations patches are applied in developer friendly way so it is visible which ones are applied in which order and (as quilt is used) they are also easy to refresh and edit.

But not in Fedora. Here we have %setup and %patch macros which use workflow from 80’s. Yes, patch <pX file.patch is not modern way of handling patches which may need work. Especially when you first fetch and install all build dependencies just to get build failed cause nth patch does not fully apply. Or when your work requires to alter patches 3rd, 7th and 13th.

Sure, there is %autosetup macro which should solve a problem. But it does not. There are packages where some patches are reverse applied or with other patch level than 1. I saw also ones where there is extra directory change during applying diffs.

So dear package maintainers — please migrate to %autosetup (with quilt or git) to make life of other developers easier. I think that there will be more people satisfied when this will happen than just me.

%patch should DIE

3 thoughts on “%patch should DIE

  • 13th February 2014 at 20:28

    Editing a %patch is straightforward:

    1. tar xvf foo-1.2.3.tar.xz
    2. cp -pr foo-1.2.3 foo-1.2.3-fix-bar
    3. cd foo-1.2.3-fix-bar ; patch -p1 <…/foo-1.2.3-fix-bar.patch
    4. edit whatever you want in foo-1.2.3-fix-bar
    5. cd .. ; diff -Nur foo-1.2.3 foo-1.2.3-fix-bar >foo-1.2.3-fix-bar.patch

    The first 2 steps can easily be done in a graphical file manager such as Krusader, and in fact that’s how I do them. Step 4 can be done with ANY text editor, IDE etc., I use the built-in editor in Krusader (based on the KatePart, like KWrite, Kate, KDevelop etc.) most of the time.

    I don’t see where the problem lies.

    I don’t like the inflexible %autosetup approach, which can require you to needlessly rediff patches from upstream or from other distros just to get the “correct” -p level. In addition, %autosetup does not support conditionally applied patches, which we sometimes need (e.g., for some packages, there was a patch that makes them support a newer libpng, but ONLY the newer version, so it had to be applied only on the Fedora versions shipping the new libpng). As for the ordering, in the KDE SIG, we typically use patches 0-99 for distro patches, 100-199 for backports from upstream, and 200 and above for various things depending on the package. Sometimes an upstream patch needs to be applied before a distro patch, sometimes it’s the other way round. So we need the ordering flexibility %patch gives us. Otherwise, it becomes much harder to track which patches come from upstream and can likely be dropped soon and which ones don’t.

    • 14th February 2014 at 21:55

      Your steps tell me that you probably never tried quilt or git to generate patches.

      Git way:

      1. tar xvf foo-1.2.3.tar.xz
      2. cd foo-1.2.3-fix-bar ; git init .;git add . ; git commit . -m”init”
      3. patch -p1 <…/foo-1.2.3-fix-bar.patch
      4. edit whatever you want in foo-1.2.3-fix-bar
      5. git diff >foo-1.2.3-fix-bar.patch

      No need to have second copy. With quilt:

      1. tar xvf foo-1.2.3.tar.xz
      2. cd foo-1.2.3-fix-bar ;. quilt import ../foo-1.2.3-fix-bar.patch
      3. quilt push
      4. edit whatever you want in foo-1.2.3-fix-bar
      5. quilt refresh

      Quilt way is more requiring cause you have to “quilt add” all edited files which were not in patch.

      Both ways are very useful when you have to edit few patches.

      And about variable %patch uses — I think that they can be sorted out.

      • 15th February 2014 at 02:27

        I usually do ‘quilt edit’ when editing patches with quilt. It will take care of adding original files to the ‘saved’ copy.

Comments are closed.