Remove pkg install info keeping files that were installed

mshort007 · 04-23-2019, 04:20 PM

Hello All,

I have been working on a kiosk type system where the initial install has always been from a thrumbdrive or DVD, then updates were installed much the same way by saving some configuration, wiping, installing clean the updated version from DVD in the field, then restoring settings.

The system uses a lot of media and image resources that are large and we packaged them to keep them versioned for each update. (Several GB)

We are now switching to upgrading the systems online and inplace, we did not have internet connectivity before, but now it is being offered as standard on new units and as an addon solution to existing systems.

I am looking to keep the media/image assets that have already been installed from our custom packages we made, but would like to remove the record of them having been installed.

They were isntalled using installpkg.

How can I do this? is removing the install log in /var/log/packages enough?
Are there other files to consider?

Is this a bad idea, am I being foolish in wanting to do this?

The reason for doing this is to not interfere with a series of checks that will be done to make sure all the packages for OS updates are in place and installed/upgraded. If we have the media resource packages listed somewhere as packages that were installed and the person writing the OS update portion of the system tries to removepkg on the media resource package that is now no longer to be included in the OS as a pkg, then the syncing of the media resources could pull down GB in data if all those resources are deleted, some of the sites will be using Cellular modems, and it will get very costly.

Hopefully, what I am trying to do makes sense and is logical. How can I remove the traces of an installed pkg, but still retain the installed files on the system?

Thanks for any help.

-mshort007

BW-userx · 04-24-2019, 09:05 AM

why would you want to remove any info on what is of yours installed on each system?
You could try making a backup of your packages listings

Code:

userx@slack.current.ed:~
$ file  /var/log/packages/zd1211-firmware-1.5-fw-2
/var/log/packages/zd1211-firmware-1.5-fw-2: ASCII text

they are a flat file, so you try could running

Code:

ls /var/log/packages > ~/installedPkgs

open that file and pull out all of your packages. Putting them into a different file, path/packageName

then create a loop and move them somewhere else for a backup testing area.

Code:

#!/bin/bash

move2=/storage/path/for/file/goes/here

while read f
do

sudo mv "$f" "$move2"

done < Pkgs2Move

then see what effects that has on your system. If it is not a desired effect, then you can still put them back where they were.
that loop is not tested, I just wrote it out, and it too requires proper valid data input to even come close to working.

if they are something that is within the system for updating. You can blacklist them instead. where all you need is the name.

Code:

$ bob=xfce4-weather-plugin-0.8.10-x86_64-4

gets you this

$ echo ${bob%%-[0-9]*}
xfce4-weather-plugin

that being all that is needed for the blacklist file. So roughly without further testing on everything in the packages dir.

without a path to file in the file to be read from, just the names of the package.

Code:

#!/bin/bash

while read f
do

sudo echo "${f%%-[0-9]*}" >>  /etc/slackpkg/blacklist

done < Pkgs2Move

That just prevents them from being updated, not removed from the knowledge of being installed on the system by the system.

mshort007 · 04-24-2019, 11:13 AM

Hello BW-userx,

Thank you for taking the time to thoughtfully reply and offer some ideas.

I have enough info to play with and I am sure I can figure this out now.

I really appreciate it, your ideas have been very helpful.

-mshort007

BW-userx · 04-24-2019, 11:56 AM

bassmadrigal · 04-25-2019, 04:44 AM

I'm not sure I fully understand your problem, but it seems like you might be upgrading/recompiling some official Slackware packages and you want to prevent those from being overridden by software updates using something like slackpkg. Am I close? If so, this can simply be done by adding those packages to slackpkg's blacklist as BW-userx mentioned above.

However, if this is the plan, keep in mind that as you're doing official updates, if any of those programs needed a library that had to be upgraded, it could potentially break your system. Many packages rely on specific versions of libraries. Pat tries to keep disruptive updates to a minimum on stable releases, but sometimes a security issue is a big enough problem that he decides it's worth upgrading a library, which might require rebuilding other official packages in Slackware (which he would provide those additional updates in the patches/ directory). Luckily, this hasn't happened in 14.2 so far (it happens all the time in -current, but this is to be expected on a development release), but if you do end up blacklisting official packages, make sure you have anyone updating the system to check for any updates that could potentially break your packages.

mshort007 · 04-25-2019, 10:36 AM

Hello bassmadrigal,

We created our own package, which is nothing more than a group of image/media files. No executables, no libraries, just a collection of media assets.

As we move from a system where we performed a complete hard drive wipe and reinstall of the latest packages we have twice a year, there has never been an issue since each install or upgrade was a complete fresh install of the OS.

The upgrade model is changing to being an online update, which now keeps the existing install in place. Since we will most likely be using rsync or something of the sort to maintain the media assets up to date, we just want to make sure that we can leave the files that are present in place, but remove the information for the initial install of the package without running removepkg. We are no longer going to create 3-5 GB of media assets in a few packages that are installed, and are now going to need the existing files present so we can update the media asset library using something like rsync.

The only issue is that there will be an OS package list that gets compared against and only the approved packages will be installed, and packages not in the list will be removed.

Hence the question of how to keep the files that were installed previously, but remove all traces/records of the install of that package on the system.

We are looking for the proper way to erase the fact that a package was previously installed, without removing it via removepkg or removing any of the installed pkg's contents.

-mshort007

bassmadrigal · 04-26-2019, 02:56 PM

Ok, that makes more sense. Thanks!

In that case, you could simply remove the file from the package database (/var/log/packages for 14.2 and older or /var/lib/pkgtool/packages for current and, once released, 15.0 and newer). You could also move the file to somewhere else if you want to keep a backup. However, this keeps untracked files on your system, which I, personally, am not a fan of.

Another option, and what I would probably do, is to write a script (like a SlackBuild) that would pull the latest files from the server and build a package out of them. Pat already does this with kernel-firmware SlackBuild. It will sync github and then add those files to a Slackware package. This would allow you to keep the files tracked by the package manager and allow you to easily update the package.

A simple script would be something like this:

Code:

#!/bin/bash

PRGNAM=media-assets
BUILD=${BUILD:-1}
TAG=${TAG:-_mshort}

ARCH=noarch

CWD=$(pwd)
TMP=${TMP:-/tmp}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}

cd $PKG

rsync -azP user@server:/location/to/files .

# Find the latest modified file and use the time-date as the verison
VERSION=$(find . -printf '%T+ %p\n' | sort -r | head -1 | cut -d. -f1 | sed 's/\(-\|:\)//g' | sed 's/://g'

/sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz}

You would want to make sure that the files on the server are located in the folder structure they are expected to be in on the other machines to simply keeping them up-to-date. Also, if you wanted, you could add an upgradepkg command at the end so it could upgrade the package on the system once completed running. This would allow you to automate it with something like a cron job and you could have it check daily or weekly to ensure it stays upgraded.

Code:

upgradepkg $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE

If desired, a check could be added to only generate the package if this would generate a different version from what's installed on the system. This would then allow the script to exit without generating a package if it would create the same package already installed.