I'm used to using "git diff" and "svn diff" to view changes in my development system. Is there a similar thing that works with changes between a repository package and the installed RPM? Ie. something that shows the changes in /etc hinted at by "rpm -V". I'm already using etckeeper+git but that would combine changes from updates with my own modifications.
The only thing I've found so far is a rather manual procedure:
https://serverfault.com/questions/378439/getting-diffs-for-file-changes-detected-by-rpm-v
On 6/1/20 7:25 PM, Kenneth Porter wrote:
I'm used to using "git diff" and "svn diff" to view changes in my development system. Is there a similar thing that works with changes between a repository package and the installed RPM? Ie. something that shows the changes in /etc hinted at by "rpm -V". I'm already using etckeeper+git but that would combine changes from updates with my own modifications.
The only thing I've found so far is a rather manual procedure:
https://serverfault.com/questions/378439/getting-diffs-for-file-changes-detected-by-rpm-v
You COULD diff the directories containing exploded source code .. but I don't think it will help you.
These are two totally separate programs and projects. It would be like trying to diff GNOME and KDE because they serve the same function. You could technically do it, but the result would have very little meaning as all the file names inside the code are different. The diff would be a copy of each file from both projects.
On an EL8 system, yum is a symlink to dnf. So there is NO difference between yum and dnf on EL8 (they are the exact same file .. /usr/bin/dnf).
The files for yum and dnf in /usr/bin/ are python scripts .. but they also import many python libraries .. so they are not totally contained in a single file.
--On Friday, June 05, 2020 9:10 AM -0500 Johnny Hughes johnny@centos.org wrote:
These are two totally separate programs and projects.
I'm not talking about diff'ing the yum and dnf programs. I'm talking about diffing the RPM packages that "rpm -V" reveals as changed. Such a utility would download the package if it wasn't in the cache, unpack it with cpio into a temp directory, and diff the component files against the copies on disk.
yum and dnf would only be involved because they maintain a package cache so they might be the logical place to implement a plugin to do this.
On 6/5/20 11:55 AM, Kenneth Porter wrote:
--On Friday, June 05, 2020 9:10 AM -0500 Johnny Hughes johnny@centos.org wrote:
These are two totally separate programs and projects.
I'm not talking about diff'ing the yum and dnf programs. I'm talking about diffing the RPM packages that "rpm -V" reveals as changed. Such a utility would download the package if it wasn't in the cache, unpack it with cpio into a temp directory, and diff the component files against the copies on disk.
yum and dnf would only be involved because they maintain a package cache so they might be the logical place to implement a plugin to do this.
Oh .. I misunderstood what you are after.
If you are dealing with CentOS RPMs .. you can just look at git.centos.org:
For example .. here is one CentOS Linux 7 rpm. I'll pick 389-ds-base.
Click into search and type 389-ds-base .. pick rpms/389-ds-base
Click on Branches on the left tabs .. In this example, I'll pick c7
Now if you click on the left commits tab. you will see each c7 rpm import.
if you click on the six digit number, for example, e52775 for the current latest "import 389-ds-base-1.3.10.1-9.el7_8". The result is every diff of every change for the rpm.
On 6/5/20 2:21 PM, Johnny Hughes wrote:
On 6/5/20 11:55 AM, Kenneth Porter wrote:
--On Friday, June 05, 2020 9:10 AM -0500 Johnny Hughes johnny@centos.org wrote:
These are two totally separate programs and projects.
I'm not talking about diff'ing the yum and dnf programs. I'm talking about diffing the RPM packages that "rpm -V" reveals as changed. Such a utility would download the package if it wasn't in the cache, unpack it with cpio into a temp directory, and diff the component files against the copies on disk.
yum and dnf would only be involved because they maintain a package cache so they might be the logical place to implement a plugin to do this.
Oh .. I misunderstood what you are after.
If you are dealing with CentOS RPMs .. you can just look at git.centos.org:
For example .. here is one CentOS Linux 7 rpm. I'll pick 389-ds-base.
Click into search and type 389-ds-base .. pick rpms/389-ds-base
Click on Branches on the left tabs .. In this example, I'll pick c7
Now if you click on the left commits tab. you will see each c7 rpm import.
if you click on the six digit number, for example, e52775 for the current latest "import 389-ds-base-1.3.10.1-9.el7_8". The result is every diff of every change for the rpm.
You can also do a git clone of any rpm and work with the branch on your machine:
so:
git clone https://git.centos.org/rpms/389-ds-base.git
cd 389-ds-base
git checkout c7
git log
(shows) commit e52775ada05eb168f4b1df79fc0350b5f38d494c Author: CentOS Sources bugs@centos.org Date: Tue May 12 08:34:50 2020 -0400
import 389-ds-base-1.3.10.1-9.el7_8
commit 4c04d8bc35c01089a6ec0a234558b3637603d9e1 Author: CentOS Sources bugs@centos.org Date: Tue Mar 31 05:37:27 2020 -0400
import 389-ds-base-1.3.10.1-5.el7
(and a bunch more)
If you then did:
git diff 4c04d8bc35c01089a6ec0a234558b3637603d9e1 e52775ada05eb168f4b1df79fc0350b5f38d494c > diff
then the file diff would look just like the web info you got in the link you did in my last post.
On 6/5/2020 12:21 PM, Johnny Hughes wrote:
if you click on the six digit number, for example, e52775 for the current latest "import 389-ds-base-1.3.10.1-9.el7_8". The result is every diff of every change for the rpm.
That's quite handy! But not what I'm looking for. I'm trying to figure out what edits I made to my config files.
My most recent case was trying to figure out what I'd done to my BIND files (/etc/named.*, /etc/logrotate.d/named, /var/named/*). I ended up just tarring them up and erasing and re-installing the bind package, then untarring my old config into a tmp directory and diffing the files individually, reapplying appropriate changes.
Some packages make this a bit easier, such as systemd unit files (where my customization never touches a package file) and fail2ban (where customizations go in a .local file that overrides settings in a .conf file. I much prefer this pattern, but it doesn't work with older packages like BIND. Some packages have a hybrid structure with a directory for customizations, like apache.
On Fri, Jun 5, 2020 at 12:35 PM Kenneth Porter shiva@sewingwitch.com wrote:
On 6/5/2020 12:21 PM, Johnny Hughes wrote:
if you click on the six digit number, for example, e52775 for the current latest "import 389-ds-base-1.3.10.1-9.el7_8". The result is every diff of every change for the rpm.
That's quite handy! But not what I'm looking for. I'm trying to figure out what edits I made to my config files.
don't most packages create a .rpmnew file if you've modified the previous package file ?
--On Friday, June 05, 2020 1:39 PM -0700 John Pierce jhn.pierce@gmail.com wrote:
don't most packages create a .rpmnew file if you've modified the previous package file ?
That file is created AFTER you've made edits, and reflects only the state of the file in the latest package. So it's not clear what changed from the original package that needs to be migrated into one's current settings.
As a rule I try to copy the original files to xxx.original so I can compare that to both the .rpmnew file and my working file. But I or another admin might forget to save the original. So I end up going the cpio route to extract the original files to a temp tree to do the 3-way comparison between the original, my modifications, and the latest package's modifications.
Am 05.06.20 um 23:31 schrieb Kenneth Porter:
--On Friday, June 05, 2020 1:39 PM -0700 John Pierce jhn.pierce@gmail.com wrote:
don't most packages create a .rpmnew file if you've modified the previous package file ?
That file is created AFTER you've made edits, and reflects only the state of the file in the latest package. So it's not clear what changed from the original package that needs to be migrated into one's current settings.
As a rule I try to copy the original files to xxx.original so I can compare that to both the .rpmnew file and my working file. But I or another admin might forget to save the original. So I end up going the cpio route to extract the original files to a temp tree to do the 3-way comparison between the original, my modifications, and the latest package's modifications.
Your needs are very specific. So, I think you need to write a custom script for that.
What we do here is, packaging the custom configuration files (rpm). The source package (srpm) has also the original or distribution version of the configuration file. Downloading the current original file in a pre task and patching it while building the rpm helps us to track the changes ...
-- Leon
--On Friday, June 05, 2020 1:39 PM -0700 John Pierce jhn.pierce@gmail.com wrote:
don't most packages create a .rpmnew file if you've modified the previous package file ?
That file is created AFTER you've made edits, and reflects only the state of the file in the latest package. So it's not clear what changed from the original package that needs to be migrated into one's current settings.
As a rule I try to copy the original files to xxx.original so I can compare that to both the .rpmnew file and my working file. But I or another admin might forget to save the original. So I end up going the cpio route to extract the original files to a temp tree to do the 3-way comparison between the original, my modifications, and the latest package's modifications.
I do something similar. Before editing any config file, I create a copy of it named xxx.orig. If I once forgot to do it in time, I have a helper script 'mkorig [file]' which extracts the file from the corresponding RPM. Now when doing upgrades with our package managing tool, this will upgrade using YUM/DNF and after this it's merging all config files. This goes well in ~95% of the cases. For the cases where merging wasn't possible, it produces the .rej files so one can merge by hand.
Simon
On 6/5/20 4:31 PM, Kenneth Porter wrote:
--On Friday, June 05, 2020 1:39 PM -0700 John Pierce jhn.pierce@gmail.com wrote:
don't most packages create a .rpmnew file if you've modified the previous package file ?
That file is created AFTER you've made edits, and reflects only the state of the file in the latest package. So it's not clear what changed from the original package that needs to be migrated into one's current settings.
As a rule I try to copy the original files to xxx.original so I can compare that to both the .rpmnew file and my working file. But I or another admin might forget to save the original. So I end up going the cpio route to extract the original files to a temp tree to do the 3-way comparison between the original, my modifications, and the latest package's modifications.
Do your mods in a local git repo .. if you mod the exploded tarball, do it via a spec patch.
If you mod config files .. create a separate branch from the rpm and put the mods in (if you can't do it via a spec patch).
Then when new files come in .. just reapply (or refactor if necessary) the original diff. That is exactly what we do for packages we modify .. look at Firefox as an example:
On Fri, Jun 05, 2020 at 12:34:07PM -0700, Kenneth Porter wrote:
I'm trying to figure out what edits I made to my config files.
My most recent case was trying to figure out what I'd done to my BIND files (/etc/named.*, /etc/logrotate.d/named, /var/named/*). I ended up just tarring them up and erasing and re-installing the bind package, then untarring my old config into a tmp directory and diffing the files individually, reapplying appropriate changes.
Just to mention that 'etckeeper' from EPEL is a great way of tracking changes in /etc. It interfaces nicely with yum, such that installing a package means that it will commit changes to the /etc repo. And there's a daily crontab that commits changes. You can manually commit changes as well. Then you can 'git log -p' to see what changes were made to the file over time.
It won't track /var/named/* though.
Paddy
--On Monday, June 08, 2020 5:00 PM +0100 Paddy Doyle paddy@tchpc.tcd.ie wrote:
It won't track /var/named/* though.
I love etckeeper enough that I started keeping /var/named under git, as well.
I do disable etckeeper's nightly commit as I don't want it combining unrelated changes into a single commit if I forget to commit. I have it set to block updates if there's an uncommitted change so I'll fix things when that happens.
On 6/06/20 7:34 am, Kenneth Porter wrote:
That's quite handy! But not what I'm looking for. I'm trying to figure out what edits I made to my config files.
Just mv those files that you changed (as shown by rpm -V packagename) and yum reinstall the package, then you can diff the original files to the ones you moved.
Peter
-
John Pierce -
Johnny Hughes -
Kenneth Porter -
Leon Fauster -
Paddy Doyle -
Peter -
Simon Matter