You are not logged in.
Pages: 1
After searching quite a bit in the wiki and forum I'd like to ask if there is (or should be) a solution to this use case.
It's all about handling .pacnew files that occasionally get created during updates. The idea behind it is quite nifty - a .pacnew file only gets created in an x, y, z situation, where the original config file, current config file and new config file are all different. So far so good, but my frustration comes when I use pacdiff, which to my knowledge only offers a comparison between the current config file and the new config file.
Assuming the changes made to the current config file are always based on the original config file, and there are generally good reasons to make custom modifications to config files, 9 out of 10 times what is most interesting to me is what de developers changed and whether or not I want/have to incorpocate those changes to my custom configuration. In some cases it even makes no sense to compare to the current config, for instance with /etc/shadow or the mirrorlist.
So is there a way to make pacdiff or an alternative tool show the diff between the original config and the new config, or a three-way diff involving all three files?
Offline
pacdiffviewer (part of yaourt) can save backup files and then tries to auto-merge the changes by seeing if the diff between backup versions can cleanly apply to the current config file.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
http://vimcasts.org/episodes/fugitive-v … h-vimdiff/ ignore the git bits
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
pacdiff can run any difference program by setting the DIFFPROG environment variable.
So just write a script to extract the previous version and do a 3-way difference and use that as the difference program.
E.g. something like:
#!/bin/bash
trap 'rm -f $prevfile ' EXIT
mktmp() { mktemp -q -p ${2:-${TMPDIR:-/tmp}} "${1:-${0//*\//}}.XXXXXXXX" ; }
prevfile=$(mktmp)
download() {
printf " > Previous version ($2) not in pacman cache; downloading from Arch Linux Archive...\n"
pushd /var/cache/pacman/pkg >/dev/null
curl -O# http://ala.seblu.net/packages/${1::1}/$1/$1-$2-$3.pkg.tar.xz
popd >/dev/null
}
if [[ "${1##*.}" == "pacnew" ]]; then
printf "--> Getting old version of $2\n"
pkgname=$(pacman -Qqo "$2")
printf " > provided by $pkgname package\n"
# get the from/to versions of the latest upgrade
versions=($(awk '/upgraded '"$pkgname"' / {split($0,a,"[()]"); split(a[2],b)} END {printf "%s %s", b[1], b[3]}' /var/log/pacman.log))
# determine package architecture
[[ -e "/var/cache/pacman/pkg/${pkgname}-${versions[1]}-any.pkg.tar.xz" ]] && arch="any" || arch=$HOSTTYPE
# the cached 'from' package (download from ALA if missing)
cached="/var/cache/pacman/pkg/${pkgname}-${versions[0]}-${arch}.pkg.tar.xz"
[[ ! -e $cached ]] && download $pkgname ${versions[0]} $arch
# get 'from' version of the file
tar -xOJf $cached "${2:1}" >| $prevfile
vim -d "$1" "$2" "$prevfile"
else
vim -d "$1" "$2"
fiOffline
Search for pacmerge - it does a three way diff for you.
Offline
Search for pacmerge - it does a three way diff for you.
pacmerge-git (if that is what you are referring to) is no longer in the AUR -- apparently no one thought it worth uploading to AUR4. And it also seems to be written in haskell for the purpose of invoking sdiff.
So... a 700 MB makedepends on ghc, another makedepends on haskell-directory-tree which is ALSO no longer in the AUR, and I am inclined to think that particular package is not worth the bother.
As far as I can tell it doesn't do a three-way diff anyway, and unlike most other alternatives doesn't allow you to specify a different diffedit command.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
For a git-based approach, there is pacmarge.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
That was the one I as meaning....
Offline
Thanks for all the replies and the tips. Pacmarge seems to be just what I need, so that will be my first weapon of choice for now. Ukhippo's script also looks quite elegant. Thanks again!
Offline
Pages: 1