Patching packages

This article covers how to create and how to apply patches to packages in the Arch Build System (ABS).

Related articles

A patch describes a set of line changes for one or multiple files. Patches are typically used to automate the changing of source code.

Creating patches
Note: If you only need to change one or two lines, you might want to use sed instead.

The diff tool compares files line by line. If you save its output you have got a patch, e.g. diff --unified --recursive --text foo bar > patch. If you pass directories diff will compare the files they contain.

  1. Delete the src directory if you have already built the package.
  2. Run makepkg --nobuild which will download and extract the source files, specified in PKGBUILD, but not build them. If the system you are making the patch on does not have the required dependencies, you may have to run makepkg --nobuild --nodeps instead.
  3. Create two copies of the extracted directory in the src directory, one as a pristine copy and one for your altered version. We will call them and .
  4. Make your changes in the directory.
  5. Run and check if the patch looks good.
  6. Run to create the patch.
  7. Change into the directory and apply the patch using . Verify that the patch is working by building and installing the modified package with .
Note: You can also create patches with Git using git diff or git format-patch .

See diff(1) and for more info.

Applying patches

This section outlines how to apply patches you created or downloaded from the Internet from within a PKGBUILD's function. Follow these steps:

  1. Add an entry to the array of the PKGBUILD for the patch file, separated from the original source url by a space. If the file is available online, you can provide the full URL and it will automatically be downloaded and placed in the src directory. If it is a patch you created yourself, or is otherwise not available, you should place the patch file in the same directory as the PKGBUILD file, and just add the name of the file to the source array so that it is copied into the src directory. If you redistribute the PKGBUILD, you should, of course, include the patch with the PKGBUILD.
  2. Then use or (from ) to update the array. Or manually add an entry to the array; you can generate the sum of your patch using sha512sum tool.
  3. Create the function in the PKGBUILD if one is not already present.
  4. The first step is to change into the directory that needs to be patched (in the function, not on your terminal! You want to automate the process of applying the patch). You can do this with something like . $pkgname-$pkgver is often the name of a directory created by untarring a downloaded source file, but not in all cases.
  5. Now you simply need to apply the patch from within this directory. This is very simply done by adding to your function, changing pkgname.patch to the name of the file containing the diff (the file that was automatically copied into your src directory because it was in the array of the PKGBUILD file).

An example prepare-function:

Alternatively, you can use the flag of without having to cd first. The example above would then become:

Run (from the terminal now). If all goes well, the patch will be automatically applied, and your new package will contain whatever changes were included in the patch. If not, you may have to experiment with the option of patch. While experimenting, you might find , or --verbose options usable. Read for more information.

Basically it works as follows. If the diff file was created to apply patches to files in , the diff files will be applied to . You are running it from within the yourversion/ directory (because you would cd into that directory in the PKGBUILD), so when patch applies the file, you want it to apply it to the file , taking off the part. does this, by removing one directory from the path. However, if the developer patched in , you need to remove two directories, so you use .

If you do not apply a option, it will take off all directory structure. This is OK if all the files are in the base directory, but if the patch was created on and one of the edited files was , and you run the patch without a option from within , it will try to patch a file named yourversion/file.

Most developers create patches from the parent directory of the directory that is being patched, so will usually be right.

Using quilt

A simpler way to create patches is using which provides better support for managing many patches, such as applying patches, refreshing patches, and reverting patched files to original state. is used on Debian to manage their patches. See Using Quilt for basic information about basic quilt usage to generate, apply patches, and reverting patched files.

gollark: More like micromanagement by someone who believes that they have the right to control fansites too.
gollark: (this is now up on the forums).
gollark: ```Unfortunately, it is unavailable, possibly forever, because (according to an email):Thank you for your request to access the Dragon Cave API from host dc.osmarks.tk. At this time, your request could not be granted, for the following reason: You have, through your own admission on the forums, done the exact thing that got EATW banned from the API.This may be a non-permanent issue; feel free to re-submit your request after correcting any issue(s) listed above.Thanks, T.J. Land presumably due to this my server and computer (yes, I should use a VPS, whatever) can no longer access DC. Whether this is sickness checking, scraping, or using EATW's approximation for optimal view count I know not, but oh well. Due to going against the unwritten rules of DC (yes, this is why I was complaining about ridiculous T&C issues) this hatchery is now nonfunctional. Service may be restored if I actually get some notification about what exactly the problem is and undoing it will not make the whole thing pointless. The text at the bottom is quite funny, though.```
gollark: I could add a T&C stating that it is the hatchery's automatic systems' prerogative to take stuff which is sick out of rotation, but none would care.
gollark: They effectively give helping permission by submitting it to a hatchery, but that's irrelevant.

See also
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.