Difference between revisions of "Pacman/Pacnew and Pacsave"

From ArchWiki
Jump to: navigation, search
m (.pacorig stub)
(.pacorig: I hope I got this right...)
Line 45: Line 45:
 
===.pacorig===
 
===.pacorig===
  
.pacorig files are created when... TODO
+
When an existing file (usually configurations found in <code>/etc</code>) is encountered during package installation or upgrade that is not listed as belonging to any already installed package, but marked as 'backup file' (see the <code>'''.pacsave'''</code> section above) in the package of the current operation, then it will be saved with a <code>'''.pacorig'''</code> extension and replaced with the file from the package.
 +
Usually this happens when a configuration file has changed its ownership from one package to another.
 +
If such a file were not listed as 'backup file', pacman would abort its operation with a file conflict error.
  
 
==Managing .pac* Files==
 
==Managing .pac* Files==

Revision as of 00:27, 23 December 2008


Introduction

During package upgrades or removal pacman sometimes warns that files — usually configurations in /etc — are being installed with a .pacnew extension or backed up with a .pacsave extension.

A .pacnew file is created during a package upgrade (pacman -U or pacman -Su) to avoid overwriting a file which already exists and was previously modified by the user. When this happens a message like the following will appear in the output of pacman:

warning: /etc/pam.d/usermod installed as /etc/pam.d/usermod.pacnew

A .pacsave file is created during a package removal (pacman -R, which is also called automatically by pacman -U and pacman -Su) when the pacman database indicates that a certain file owned by the package should be renamed with a .pacsave extension if it was previously modified by the user. When this happens pacman outputs a message like the following:

warning: /etc/pam.d/usermod saved as /etc/pam.d/usermod.pacsave

These files require manual intervention from the user and it is good practice to handle them immediately after every invocation of pacman. If left unhandled they will accumulate and clutter up the filesystem, and installed software may become misconfigured, causing undesired behavior that can be difficult to troubleshoot.

When .pac* Files Are Created

.pacnew

For each file in a package being upgraded, pacman cross-compares three MD5 sums generated from the file's contents: one sum for the version originally installed by the package, one for the version currently in the filesystem, and one for the version in the new package. If the version of the file currently in the filesystem has been modified from the version originally installed by the package, pacman cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, pacman saves the new version with a .pacnew extension and leaves the modified version untouched.

Going into further detail, the 3-way MD5 sum comparison results in one of the following outcomes:

original = X, current = X, new = X 
All three versions of the file have identical contents, so overwriting is not a problem. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)
original = X, current = X, new = Y 
The current version's contents are identical to the original's, but the new version is different. Since the user hasn't modified the current version and the new version may contain improvements or bugfixes, overwrite the current version with the new version and do not notify the user. This is the only auto-merging of new changes that pacman is capable of performing.
original = X, current = Y, new = X 
The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.
original = X, current = Y, new = Y 
The new version is identical to the current version. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)
original = X, current = Y, new = Z 
All three versions are different, so leave the current version in place, install the new version with a .pacnew extension and warn the user about the new version. The user will be expected to manually merge any changes necessary from the new version into the current version.

.pacsave

A package's PKGBUILD file specifies which files should be backed up when the package is upgraded or removed. For example, the PKGBUILD for pulseaudio contains the following line:

backup=('etc/pulse/client.conf' 'etc/pulse/daemon.conf' 'etc/pulse/default.pa')

If the user has modified one of the files specified in backup then that file will be renamed with a .pacsave extension and will remain in the filesystem after the rest of the package is upgraded or removed.

Template:Box Note

.pacorig

When an existing file (usually configurations found in /etc) is encountered during package installation or upgrade that is not listed as belonging to any already installed package, but marked as 'backup file' (see the .pacsave section above) in the package of the current operation, then it will be saved with a .pacorig extension and replaced with the file from the package. Usually this happens when a configuration file has changed its ownership from one package to another. If such a file were not listed as 'backup file', pacman would abort its operation with a file conflict error.

Managing .pac* Files

Always pay attention to the output of pacman. When upgrading or removing a large number of packages, important messages may scroll by too quickly or beyond the terminal's buffer; fortunately there are other ways to discover whether a pacman operation created any .pac* files.

If the user or a cron job has run updatedb to update the locate database since pacman was last run, the files can be located with:

locate .pac

A slower method (unless the user manually runs updatedb before locate) that always yields up-to-date results is the find command:

find / -name "*.pac*"

Searching the pacman log with egrep can be as fast as the locate method above and it will always yield up-to-date results; however, it doesn't record which files remain in the filesystem or have been removed:

egrep "pac(new|save)" /var/log/pacman.log

Template:Box Note

Once all existing .pac* files have been located the user may handle them manually using merge tools such as vimdiff (part of vim) or ediff (part of emacs) and by deleting the .pac* files which the user is certain they no longer need. A few third-party utilities providing various levels of automation for these tasks are available from the community repo and AUR (Arch doesn't provide official utilities for .pac* file management):

  • Dotpac — Basic interactive script with ncurses-based text interface and helpful walkthrough. No merging or auto-merging features.
  • pacdiff — Very minimal and undocumented CLI script. Part of the pacman-contrib package in the community repo.
  • pacdiffviewer — Full-featured interactive CLI script with auto-merging capability. Part of the yaourt package.

External Links