I am wanting to be able to reimplement the same changes when I install a new release down the road, so I'm trying to figure out a good way to keep track of what I changed.
Any ideas?
topic title: Is there an easy way to track what changes are made?
13 posts
• Page 1 of 1
-
thrifteePosts: 604
- Joined: 27 Feb 2009
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#2
If you are tracking changes to a live antix16, you can create a manifest of all the files (and dirs) residing in the upper overlayfs layer.
I'm using"root persist" (no homefs exists) so can't speak to what else needs to be considered if homefs is in the mix.
For rootfs, all the upper layer content resides under /live/aufs-ram/upper/
sudo user, in terminal:
cd /live/aufs-ram/upper/
ls -alR>>/tmp/mymanifest.txt
could be used to generate a list, but you probably would want to use multiple ls calls from selected subdirs
and ignore, for instance, the content under /live/aufs-ram/upper/tmp/
ps: refer to"man ls" (you might wish to use different switches so that the output is formatted differently)
The above is fairly unwieldy. Sifting through the listed files doesn't help to track"whatall packages were installed".
Live (same when installed to disk, IIRC) a Day1"as issued" package manifest is preinstalled. See:
/usr/share/antiX/installed-packages.txt
On demand, you can create a"debian packages installed as of today" via a command like
sudo dpkg --list >>~installed-packages-detailed.txt
and compare/diff the 2 manifest files to determine what has changed
(see: shell commands"man diff" and"man uniq", or install a GUI diff viewer e.g."meld" or"diffuse")
Dated logfiles are generated for package operations performed via synaptic
See: /root/.synaptic/log/*
and a comprehensive logfile (contains tranactions performed via synaptic as wells as via commandline apt)
is written to /var/log/dpkg.log
If logrotate is in effect (see"man logrotate") you may find multiple sequential logfiles present rather than a single logfile
Toward automating the reconstruction, you can create a shell script and
as you make customization/changes, add steps to the script, like so:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/KERNELULTRAS/LegacyIce-antiX/blob/master/antiX-15/legacyice.sh"
linktext was:"https://github.com/KERNELULTRAS/LegacyI ... gacyice.sh"
====================================
^----- FYI, I tested this (as a user) and it worked perfectly in reproducing the author's described outcome.
Are you familiar with the"stat" command?
stat ~/.bashrc
In the output of the stat command, note that each file, each dir, bears multiple timestamps
indicating dates: Created, LastModified, and LastAccessed
-=-
Although the default configuration (antix, same as with most desktop-oriented distros) is sloppy about, or entirely skips, updating the"LastAccessed" timestamp in order to reduce disk I/O operations... we can still put the"find" command to use for time-oriented searches. Examples:
find . -mtime +30>>filelist.txt[/color
(List all files under current directory modified more than given number of days ago)
find . -mtime 14>>filelist.txt
(List all files under current directory modified within the past 14 days)
YMMV. You'll notice many misleading (earlier dates preserved, by dpkg installer) ctime and mtime designations
but dated find operations are still useful e.g."modified more recently than the date I installed this O/S"
it's late. I didn't proofread this post. Hopefully these ideas will at least get ya pointed in the right direction
I'm using"root persist" (no homefs exists) so can't speak to what else needs to be considered if homefs is in the mix.
For rootfs, all the upper layer content resides under /live/aufs-ram/upper/
sudo user, in terminal:
cd /live/aufs-ram/upper/
ls -alR>>/tmp/mymanifest.txt
could be used to generate a list, but you probably would want to use multiple ls calls from selected subdirs
and ignore, for instance, the content under /live/aufs-ram/upper/tmp/
ps: refer to"man ls" (you might wish to use different switches so that the output is formatted differently)
The above is fairly unwieldy. Sifting through the listed files doesn't help to track"whatall packages were installed".
Live (same when installed to disk, IIRC) a Day1"as issued" package manifest is preinstalled. See:
/usr/share/antiX/installed-packages.txt
On demand, you can create a"debian packages installed as of today" via a command like
sudo dpkg --list >>~installed-packages-detailed.txt
and compare/diff the 2 manifest files to determine what has changed
(see: shell commands"man diff" and"man uniq", or install a GUI diff viewer e.g."meld" or"diffuse")
Dated logfiles are generated for package operations performed via synaptic
See: /root/.synaptic/log/*
and a comprehensive logfile (contains tranactions performed via synaptic as wells as via commandline apt)
is written to /var/log/dpkg.log
If logrotate is in effect (see"man logrotate") you may find multiple sequential logfiles present rather than a single logfile
Toward automating the reconstruction, you can create a shell script and
as you make customization/changes, add steps to the script, like so:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/KERNELULTRAS/LegacyIce-antiX/blob/master/antiX-15/legacyice.sh"
linktext was:"https://github.com/KERNELULTRAS/LegacyI ... gacyice.sh"
====================================
^----- FYI, I tested this (as a user) and it worked perfectly in reproducing the author's described outcome.
Are you familiar with the"stat" command?
stat ~/.bashrc
In the output of the stat command, note that each file, each dir, bears multiple timestamps
indicating dates: Created, LastModified, and LastAccessed
-=-
Although the default configuration (antix, same as with most desktop-oriented distros) is sloppy about, or entirely skips, updating the"LastAccessed" timestamp in order to reduce disk I/O operations... we can still put the"find" command to use for time-oriented searches. Examples:
find . -mtime +30>>filelist.txt[/color
(List all files under current directory modified more than given number of days ago)
find . -mtime 14>>filelist.txt
(List all files under current directory modified within the past 14 days)
YMMV. You'll notice many misleading (earlier dates preserved, by dpkg installer) ctime and mtime designations
but dated find operations are still useful e.g."modified more recently than the date I installed this O/S"
it's late. I didn't proofread this post. Hopefully these ideas will at least get ya pointed in the right direction
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#3
Skidoo, thanks for putting that all down. Yes, its live antiX16-full-386 running persist-all spacefm-icewm desktop. From your answer, I can see you understand why I'd be asking this before I get the out of space message and am forced to remaster, because once I remaster, I can't see what was there separately anymore.
I was thinking of archiving the upper folders before each remaster, and exclude /tmp. I was thinking of just keeping the copies of the persistence files before the remaster, so I could just mount them and drill through them with ncdu and mc. Its too bad ncdu doesn't have an open or view option as that would make it easier.
------------------
The history kept by synaptic is what I used to remember what packages I'd installed since creating the USB flashdrive. I generally don't use dpkg or apt-get to install packages for fear things like menus won't get updated. I am beginning to think I should try to figure out how to create packages and put my changes in them as I go, but I've never done that and would need to learn how, etc.
-------------------------
-------------------------
In most cases the last modified date should be ok, I think, as long as I take care to touch anything not installed by a package. I can see where I haven't done that. It would be nice if ncdu displayed the last modified dates.
I looked at the LegacyIce install script, and yes, I have about 1/2 dozen small packages I need to install, and other default ones I could remove. Maybe if I made my other changes into package(s) it would at minimum keep them organized.
Thanks again for the detailed reply. I could tell it was complex, but underestimated it. It shows that I really should try to keep my mods to a minimum in the first place and organize the ones I do make if I want to make migrating them a reasonably easy process.
------------------skidoo wrote:If you are tracking changes to a live antix16, you can create a manifest of all the files (and dirs) residing in the upper overlayfs layer.
I'm using"root persist" (no homefs exists) so can't speak to what else needs to be considered if homefs is in the mix.
For rootfs, all the upper layer content resides under /live/aufs-ram/upper/
sudo user, in terminal:
cd /live/aufs-ram/upper/
ls -alR>>/tmp/mymanifest.txt
could be used to generate a list, but you probably would want to use multiple ls calls from selected subdirs
and ignore, for instance, the content under /live/aufs-ram/upper/tmp/
ps: refer to"man ls" (you might wish to use different switches so that the output is formatted differently)
The above is fairly unwieldy. Sifting through the listed files doesn't help to track"whatall packages were installed".
I was thinking of archiving the upper folders before each remaster, and exclude /tmp. I was thinking of just keeping the copies of the persistence files before the remaster, so I could just mount them and drill through them with ncdu and mc. Its too bad ncdu doesn't have an open or view option as that would make it easier.
------------------
-------------------------skidoo wrote:Live (same when installed to disk, IIRC) a Day1"as issued" package manifest is preinstalled. See:
/usr/share/antiX/installed-packages.txt
On demand, you can create a"debian packages installed as of today" via a command like
sudo dpkg --list >>~installed-packages-detailed.txt
and compare/diff the 2 manifest files to determine what has changed
(see: shell commands"man diff" and"man uniq", or install a GUI diff viewer e.g."meld" or"diffuse")
Dated logfiles are generated for package operations performed via synaptic
See: /root/.synaptic/log/*
and a comprehensive logfile (contains tranactions performed via synaptic as wells as via commandline apt)
is written to /var/log/dpkg.log
If logrotate is in effect (see"man logrotate") you may find multiple sequential logfiles present rather than a single logfile.
The history kept by synaptic is what I used to remember what packages I'd installed since creating the USB flashdrive. I generally don't use dpkg or apt-get to install packages for fear things like menus won't get updated. I am beginning to think I should try to figure out how to create packages and put my changes in them as I go, but I've never done that and would need to learn how, etc.
-------------------------
skidoo wrote:Toward automating the reconstruction, you can create a shell script and
as you make customization/changes, add steps to the script, like so:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/KERNELULTRAS/LegacyIce-antiX/blob/master/antiX-15/legacyice.sh"
linktext was:"https://github.com/KERNELULTRAS/LegacyI ... gacyice.sh"
====================================
^----- FYI, I tested this (as a user) and it worked perfectly in reproducing the author's described outcome.
Are you familiar with the"stat" command?
stat ~/.bashrc
In the output of the stat command, note that each file, each dir, bears multiple timestamps
indicating dates: Created, LastModified, and LastAccessed
-=-
Although the default configuration (antix, same as with most desktop-oriented distros) is sloppy about, or entirely skips, updating the"LastAccessed" timestamp in order to reduce disk I/O operations... we can still put the"find" command to use for time-oriented searches. Examples:
find . -mtime +30>>filelist.txt[/color
(List all files under current directory modified more than given number of days ago)
find . -mtime 14>>filelist.txt
(List all files under current directory modified within the past 14 days)
YMMV. You'll notice many misleading (earlier dates preserved, by dpkg installer) ctime and mtime designations
but dated find operations are still useful e.g."modified more recently than the date I installed this O/S"
it's late. I didn't proofread this post. Hopefully these ideas will at least get ya pointed in the right direction
-------------------------
In most cases the last modified date should be ok, I think, as long as I take care to touch anything not installed by a package. I can see where I haven't done that. It would be nice if ncdu displayed the last modified dates.
I looked at the LegacyIce install script, and yes, I have about 1/2 dozen small packages I need to install, and other default ones I could remove. Maybe if I made my other changes into package(s) it would at minimum keep them organized.
Thanks again for the detailed reply. I could tell it was complex, but underestimated it. It shows that I really should try to keep my mods to a minimum in the first place and organize the ones I do make if I want to make migrating them a reasonably easy process.
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#4
(sudo locate exclude and peruse the paths itemized in the various *.exclude files)
...could add a line to the persist-save script cp blah/blah/rootfs blah/blah/rootfs.timestamp
to automatically copy the rootfs file prior to updating its content.
Using on-demand save (vs only at shutdown) it's forensically interesting to see"what files have changed during this session".
Interesting, as in, install packageX then immediately purge, then examine whether (usually) stray files are left behind.
You can create a"show me" script (copy and mod the line within persist-save which calls rsync), adding options vv (or vvv for super-verbose log output) and specify --logfile=/tmp/whatever.txt to have it log every file processed. Thing is, it does blab EVERY file, even those unchanged; begs followup use of a script which parses out the"interesting" lines from the logfile. If you're interested, I'll hunt down the loooong rsync string I hammered out & post it. I never did bother scripting a parser because, on a given run, what was"interesting" often varied.
The only reason(s) I wound up using ncdu instead of mc:
-- I too often wound up opening files in vim while nagivating within mc, due to fat-fingered typing
-- my terminal emulator was grabbing the"F10" keypress intended to exit mc, forcing me to Ctrl+z to exit then killall mc
but unless you mod the excludes, live-remaster does not preserve:
/var/log/apt/history.log
/var/log/dpkg.log
============
(unrelated) off-the-cuff tip:
Prior to running on-demand persist-save, you should close/exit firefox.
If you do not, you'll likely lose any fresh bookmarks added this session and ff session-restore will (due to overlapping timestamps) discard today's session file(s) at next launch & fallback to restoring the prior session.
============
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.mxlinux.org"
linktext was:"https://forum.mxlinux.org"
====================================
could probably coach you, and IIRC their packaging subforum has pinned/stickied tutorial posts. Aside from the time sink, I bristle at the overhead of the packaging files ~~ often larger than than payload being installed. Howabout: a bash script to loop mount your earlier rootfs (as you suggested in another post) which copies into place files and dirs of interest and, ala legacylyte, apt-get installs fresh packages that you have no custom config files for (and/or expect have available updated versions, vs what was installed previously). That, maintaining a simple linear bash script, seems like an easy route.
I advise against doing so. You'd need to exclude hella more than just tmpI was thinking of archiving the upper folders before each remaster, and exclude /tmp.
(sudo locate exclude and peruse the paths itemized in the various *.exclude files)
Yes! Although I only do it occasionally, manually...I was thinking of just keeping the copies of the persistence files before the remaster
...could add a line to the persist-save script cp blah/blah/rootfs blah/blah/rootfs.timestamp
to automatically copy the rootfs file prior to updating its content.
Using on-demand save (vs only at shutdown) it's forensically interesting to see"what files have changed during this session".
Interesting, as in, install packageX then immediately purge, then examine whether (usually) stray files are left behind.
You can create a"show me" script (copy and mod the line within persist-save which calls rsync), adding options vv (or vvv for super-verbose log output) and specify --logfile=/tmp/whatever.txt to have it log every file processed. Thing is, it does blab EVERY file, even those unchanged; begs followup use of a script which parses out the"interesting" lines from the logfile. If you're interested, I'll hunt down the loooong rsync string I hammered out & post it. I never did bother scripting a parser because, on a given run, what was"interesting" often varied.
Within mc, clicking"Size" column header sorts by size and F3 commands"view file content".Its too bad ncdu doesn't have an open or view option as that would make it easier.
The only reason(s) I wound up using ncdu instead of mc:
-- I too often wound up opening files in vim while nagivating within mc, due to fat-fingered typing
-- my terminal emulator was grabbing the"F10" keypress intended to exit mc, forcing me to Ctrl+z to exit then killall mc
live-remaster does preserve (does not exclude) the /root/.synaptic/log/* files,The history kept by synaptic is what I used to remember what packages I'd installed since creating the USB flashdrive.
but unless you mod the excludes, live-remaster does not preserve:
/var/log/apt/history.log
/var/log/dpkg.log
============
(unrelated) off-the-cuff tip:
Prior to running on-demand persist-save, you should close/exit firefox.
If you do not, you'll likely lose any fresh bookmarks added this session and ff session-restore will (due to overlapping timestamps) discard today's session file(s) at next launch & fallback to restoring the prior session.
============
In synaptic, search"desktop-session-antix" and view the list of its"Installed Files". Note the references to 'apt.conf.d' ~~ those serve as apt post-install (and post-uninstall) hooks. ALL apt install/uninstall/purge ops trigger the hook, regardless whether performed via commandline or via synaptic, causing the /usr/local/bin/desktop-menu script to be run (which performs the menu updates). Caveat: above I typed"ALL", but I can't recall whether installations performed via gdebi utility will trigger the hook.I generally don't use dpkg or apt-get to install packages for fear things like menus won't get updated.
stevo or asquerth over at the MX forumMaybe if I made my other changes into package(s) it would at minimum keep them organized.
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.mxlinux.org"
linktext was:"https://forum.mxlinux.org"
====================================
could probably coach you, and IIRC their packaging subforum has pinned/stickied tutorial posts. Aside from the time sink, I bristle at the overhead of the packaging files ~~ often larger than than payload being installed. Howabout: a bash script to loop mount your earlier rootfs (as you suggested in another post) which copies into place files and dirs of interest and, ala legacylyte, apt-get installs fresh packages that you have no custom config files for (and/or expect have available updated versions, vs what was installed previously). That, maintaining a simple linear bash script, seems like an easy route.
Well, we've only discussed the persist_all scenario. If you mount an external /home, you could choose that (same) mountpoint, or copy into place its content, into a fresh install. I avoid that (bulk copy into place, reuse same /home content across installs) because much of my"stuffs" gets filed away on external mounts rather than being saved in /home. My approach doesn't feel like I'm striving to"minimize my mods" & I hope you'll arrive at suitably worry-free"recreate it" solution.I really should try to keep my mods to a minimum in the first place
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#5
I have to think more. I need to reread your thoughts above. Yes, packaging is probably too much effort, but maybe maintaining an archive for scripts and odd files added, like icons to go with the scripts is not unmanageable. I am not adding files daily. I only do it while I'm trying to get things setup, and generally don't mess with it again until it breaks or I need to migrate it, or add a feature I suppose.
I should probably do the update/upgrade, but fear I'll crash it trying. Maybe I should have done the install, then update/upgrade, and then my little installs, and then remastered immediately.
I should probably do the update/upgrade, but fear I'll crash it trying. Maybe I should have done the install, then update/upgrade, and then my little installs, and then remastered immediately.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#6
Ok, I did the update and upgrade successfully, then saved persistence, then copied the persist files to another place, then did the remaster. It ran fine. At the end it asks to save persistence files because I have it on semi-automatic, but it shows 1008 meg reported rootfs space, 907 meg total, 957 used, 336 excluded, and 905 meg for required, as though remastering didn't clear it. If I say yes to sync file changes, it will try, but gets an rsync error 11 and fails. I'm worrying that if I try to reboot it will try to copy all that to ram.
Any ideas how to get things back to normal?
Any ideas how to get things back to normal?
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#7
I eventually said No and it rebooted, and seemed to come up ok. I had made copies of the persistence files before the update/upgrade, so it should have been easy to get it back to that point if it had failed.
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#8
After live-remaster runs, you should find that it has automatically preserved linuxfs, by renaming is to linuxfs.old
Similarly, if rootfs exists, live-remaster preserves it (provides an opportunity for rollback) renaming it to rootfs.old
If you choose to forego advance persistence setup, live-remaster does not crate a new rootfs file.
"907 meg total, 957 used... 905 meg for required"
Those totals are (necessarily) estimates. If the tool reports"successful", _that_ is what matters.
edit:
fixed typos
Hmm, I'm not sure what you're describing ~~ sounds like you're misattributing the"because" reason. The live-remaster script may ask, conditionally (if it detects persistence is in effect), ask whether you want to re-setup persistence for the remastered o/s. At that juncture, you're free to choose"no" (and I usually do so), electing to defer creation of the savefiles until @boot (setup runs automatically when you choose persist at the bootmenu and persistence has not yet been setup). Alternatively, you might defer setting up persistence until desktop session login and use the GUI tool for setup/resize persistence.At the end it asks to save persistence files because I have it on semi-automatic
After live-remaster runs, you should find that it has automatically preserved linuxfs, by renaming is to linuxfs.old
Similarly, if rootfs exists, live-remaster preserves it (provides an opportunity for rollback) renaming it to rootfs.old
If you choose to forego advance persistence setup, live-remaster does not crate a new rootfs file.
Manually copying linuxfs and roofs"just in case" is fine, just understand that those copies are redundant.I had made copies of the persistence files before the update/upgrade, so it should have been easy to get it back to that point if it had failed.
Without a screenshot, I'm at a loss to understand what/why. The dialogbox which reported those totals, was it titled"successful" (or"succeeded")... and"rsync error 11" was displayed later?but it shows 1008 meg reported rootfs space, 907 meg total, 957 used, 336 excluded, and 905 meg for required, as though remastering didn't clear it. If I say yes to sync file changes, it will try, but gets an rsync error 11 and fails. I'm worrying that if I try to reboot it will try to copy all that to ram.
"907 meg total, 957 used... 905 meg for required"
Those totals are (necessarily) estimates. If the tool reports"successful", _that_ is what matters.
edit:
fixed typos
Last edited by skidoo on 29 Nov 2016, 06:14, edited 1 time in total.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#9
At the end of the remaster it asked to reboot and I think I said yes, and that was when it got into trouble.
All is ok now, it looks. Copying to ram was 0 went I just booted.
Yes, I expected it would make backup copies, but I had oodles of space, and was willing to waste a bit of it temporarily and a couple minutes of my time to be sure I wouldn't lose my efforts to that point.
I think I'm all ok at this point. Its been through 2 reboots now and the persistence save option looks back to normal with nothing to do now. I do appreciate you taking time to help.
All is ok now, it looks. Copying to ram was 0 went I just booted.
Yes, I expected it would make backup copies, but I had oodles of space, and was willing to waste a bit of it temporarily and a couple minutes of my time to be sure I wouldn't lose my efforts to that point.
I think I'm all ok at this point. Its been through 2 reboots now and the persistence save option looks back to normal with nothing to do now. I do appreciate you taking time to help.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#10
Initially I was thinking to merge the lists back in with version and descriptions to make it readable, but never got there...
I wrote a script that compares the original package list, a saved list (from a backup), and the current list, and creates add and remove lists for each that could be used to feed apt-get to install or purge starting from a fresh install to get to the same packages.skidoo wrote:snip...
The above is fairly unwieldy. Sifting through the listed files doesn't help to track"whatall packages were installed".
Live (same when installed to disk, IIRC) a Day1"as issued" package manifest is preinstalled. See:
/usr/share/antiX/installed-packages.txt
On demand, you can create a"debian packages installed as of today" via a command like
sudo dpkg --list >>~installed-packages-detailed.txt
and compare/diff the 2 manifest files to determine what has changed
(see: shell commands"man diff" and"man uniq", or install a GUI diff viewer e.g."meld" or"diffuse")
Initially I was thinking to merge the lists back in with version and descriptions to make it readable, but never got there...
Code: Select all
#
!/bin/bash
# pkgschgd.sh - compares original installed packages (saved at /usr/share/antiX/installed-packages.txt)
# to current packages list and generates files of pkgschgd.add.txt and pkgschgd.remove.txt
# Should be able to process adds with: xargs -a pkgschgd.add.txt apt-get install
# Should be able to process removes with: xargs -a pkgschgd.remove.txt apt-get purge
# antix original install package list has no headings or states columns
# get package names and sort to origf1s
cp /usr/share/antiX/installed-packages.txt ./
awk '{print $1}' installed-packages.txt | sort > origf1s
# package list from dpkg -l has headings and states fields in front of package name
# delete 5 heading lines, delete 1st 4 characters from each line,
dpkg -l > current.installed-packages.txt
sed '1,5 d' current.installed-packages.txt | sed 's/^....//g' > currentf
# get package names and sort to currentfs
awk '{print $1}' currentf | sort > currentf1s
# compare 2 sorted files, put adds in one file and removed in another
comm -2 -3 currentf1s origf1s > pkgschgd.add.txt
comm -1 -3 currentf1s origf1s > pkgschgd.remove.txt
# saved package list (from backup when system was good) from dpkg -l has headings and states fields in front of package name
# delete 5 heading lines, delete 1st 4 characters from each line
if [ -f saved.installed-packages.txt ]
then
sed '1,5 d' saved.installed-packages.txt | sed 's/^....//g' > savedf
# get package names and sort to savedf1s
awk '{print $1}' savedf | sort > savedf1s
# compare 2 sorted files, put adds in one file and removed in another
comm -2 -3 savedf1s origf1s > pkgschgd.adduptosaved.txt
comm -1 -3 savedf1s origf1s > pkgschgd.removeuptosaved.txt
# compare 2 sorted files, put adds in one file and removed in another
comm -2 -3 currentf1s savedf1s > pkgschgd.addedsavedtocurrent.txt
comm -1 -3 currentf1s savedf1s > pkgschgd.removesavetocurrent.txt
else
echo ./saved.installed-packages.txt not found... If it exists, comparisons will be generated in 3 way mode...
fi
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#11
Thanks for sharing your script.Your approach of simply comparing"orig" vs"now" seems more reasonable, more practical. The prospect of munging dpkg.log, transaction by transaction, would be both tedious and would invite error ~~ potentially incomplete, if logrotate has not been in effect... and open-ended (would need to find/open all *.gz acrhived logfiles) if logrotate has been enabled. Adding to the potential confusion, across the months there have been some packages I've removed/reinstalled a dozen or more times, e.g. testing apt update speed against various mirrors.
Instead of reinjecting description, might preserve them by deferring the awk call. Could interactively prompt to ask self during each run whether descriptions are desired in the output and conditionally strip 'em if not wanted during a given run. For my own use, my only immediate amendment to your script would be to cd /tmp atop the script rather than trusting ./ relative paths.
Code: Select all
# Should be able to process adds with: xargs -a pkgschgd.add.txt apt-get install
# Should be able to process removes with: xargs -a pkgschgd.remove.txt apt-get purgeInstead of reinjecting description, might preserve them by deferring the awk call. Could interactively prompt to ask self during each run whether descriptions are desired in the output and conditionally strip 'em if not wanted during a given run. For my own use, my only immediate amendment to your script would be to cd /tmp atop the script rather than trusting ./ relative paths.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#12
Necessity is the Mother of Invention...
Yes, I've installed and purged many packages, too, and all were"normal" from the repos and I had almost no troubles.
I know better than to install things that don't want to work, that I haven't tried before, from old releases, that give errors, into my main system. LOL, error, error, error... The pain of needing to rebuild and writing and testing the tools to do it will help me remember why I have sacrificial machines here to test things on...
In my attempt to correctly install emelfm from etch, I had to install debian-keyring, which is over 50mb, and it gives nasty warnings if I tell it to remove it.
To fix it, I'm going to take my remastered flashdrive (that's the saved files list) from a month ago, and install from it again, and then add the new packages and remove a couple, and then overlay the gleaned rsync files from /etc, /usr and /lib, overlay all from /home and /root, and hopefully that will just do it.
The reason I trimmed down to just package names was because I didn't want minor version or description differences causing the lists to get longer. I saved the files, but not sure I really need the descriptions that badly, as it doesn't look easy to get them into the other files.
Yes, I've installed and purged many packages, too, and all were"normal" from the repos and I had almost no troubles.
I know better than to install things that don't want to work, that I haven't tried before, from old releases, that give errors, into my main system. LOL, error, error, error... The pain of needing to rebuild and writing and testing the tools to do it will help me remember why I have sacrificial machines here to test things on...
In my attempt to correctly install emelfm from etch, I had to install debian-keyring, which is over 50mb, and it gives nasty warnings if I tell it to remove it.
To fix it, I'm going to take my remastered flashdrive (that's the saved files list) from a month ago, and install from it again, and then add the new packages and remove a couple, and then overlay the gleaned rsync files from /etc, /usr and /lib, overlay all from /home and /root, and hopefully that will just do it.
The reason I trimmed down to just package names was because I didn't want minor version or description differences causing the lists to get longer. I saved the files, but not sure I really need the descriptions that badly, as it doesn't look easy to get them into the other files.
-
thrifteePosts: 604
- Joined: 27 Feb 2009
#13
The xargs thing didn't work, but I went into synaptic, did a reload, and pasted in the main packages, and that did work.
So believe it or not my system survived my"save the /home" install from the flashdrive
LOL, if nothing else, I have luck on my side
And to the dev's, kudos, because this thing is pretty darned resilient! To survive my screw-ups is pretty amazing __{{emoticon}}__
Thanks Skidoo, your help and ideas made all the difference...
So believe it or not my system survived my"save the /home" install from the flashdrive
LOL, if nothing else, I have luck on my side
And to the dev's, kudos, because this thing is pretty darned resilient! To survive my screw-ups is pretty amazing __{{emoticon}}__
Thanks Skidoo, your help and ideas made all the difference...