Slackpkg cleanup after oddball install

Sometime in July I installed a clean new -current system from a local repo, then performed some necessary post-install configuration, db imports, etc. then the system was set aside until today when I needed to get it online.

I began by first trying to bring it up to date using slackpkg which had not yet been configured. After configuring and mounting the local repo I faced a wall of messages like this...

  ...
        Package xdg-desktop-portal-kde-5.22.5-x86_64-1.txz is already in cache - not downloading
        Upgrading xdg-desktop-portal-kde-5.22.5-x86_64-1...

Error: there is no installed package named xdg-desktop-portal-kde-5.22.5-x86_64-1.
       (looking for /var/lib/pkgtools/packages/xdg-desktop-portal-kde-5.22.5-x86_64-1)

        Package xfig-3.2.8b-x86_64-1.txz is already in cache - not downloading
        Upgrading xfig-3.2.8b-x86_64-1...

Error: there is no installed package named xfig-3.2.8b-x86_64-1.
       (looking for /var/lib/pkgtools/packages/xfig-3.2.8b-x86_64-1)
       ...

A quick search of LQ found this post which pointed in the right direction - thank you bassmadrigal - and this reply from phalanx which described my own installation!

The problem was that I had booted the installer from 14.2 before installing a full -current instance, and there was a change in location of the package database from 14.2 to -current.

The solution in that thread was a full resintall of 14.2 then upgrade to -current, but I wanted to avoid a full reinstall and just fix the existing installation if possible.

To do that with some degree of confidence I checked the relevant paths and files against another clean install which had been done from a -current installer boot and adjusted accordingly. I'll show everything here as a mv operation for simplicity, but where there were exisiting files in the target directories I merged their contents first, then removed the source directory.

cd /var/log

mv packages ../lib/pkgtools/.
mv scripts ../lib/pkgtools/.
mv setup ../lib/pkgtools/.
mv removed_packages pkgtools/.
mv removed_scripts pkgtools/.
mv removed_uninstall_scripts pkgtools/.

ln -s ../lib/pkgtools/packages .
ln -s ../lib/pkgtools/scripts .
ln -s ../lib/pkgtools/setup .
ln -s pkgtools/removed_packages .
ln -s pkgtools/removed_scripts .
ln -s pkgtools/removed_uninstall_scripts .

After all that slackpkg updated and upgrade-all'd successfully.

I am mostly posting this here as a reminder for myself, and also to have it all in one place for anyone else who may need it, rather than asking a question. However, if anyone should see something I have missed or wishes to comment, please post it here!

packages where moved in current then Symbolic linked. something broke your link to it or you did not say yes to slackpkg when you went to current. First time you use current and slackpkg you set your mirror to current at update. It will ask you this then set up the link.
So something happened that link never happened

Originally Posted by lovemeslk ...something broke your link to it or you did not say yes to slackpkg when you went to current. First time you use current and slackpkg you set your mirror to current at update...

I think you did not undertand my post. I did not upgrade from 14.2 to current, so there was no time at which I "went to current", this was a complete clean -current install from the start, except that it was done with the pkgtools included in the 14.2 installer (i.e. the 14.2 initrd). At the time I was updating my local network boot installer and did not have a current kernel/initrd configured so I naively booted to the 14.2 installer then installed from the -current repo. I have not fully traced how that is handled, but it is pkgtools which creates those links, and the pkgtools which did that was from 14.2. When the slackpkg from -current ran for the first time, expecting to find the newer paths it instead found nothing there and does not, apparently, move those files itself.

But I had been unaware of the pkgtools change which took place in ancient history (2018) which only shows that I have not been following -current closely the last few years! There were a few updates subsequent to this, but the big change happened in June 2018 as found in ChangeLog.txt:

Tue Jun 19 22:35:25 UTC 2018 ... testing/packages/pkgtools-15.0-noarch-20.txz: Rebuilt. This update is a bit scarier than usual, so we're going to test it here first and then move it into the main tree in a couple of days if there are no serious bug reports. It's well-tested here, and works with the slackpkg that's in -current now, but I don't know about slackpkg+ so that's another reason to let it cool down here first. The purpose of this update is to migrate the package database and directories from /var/log to /var/lib/pkgtools. /var/log was never a good place for this data, as it is considered by many to be a directory that could be wiped to free up some space. Originally the package database was in /var/adm, but the FSSTND (later FHS) group decided that directory should be a symlink to /var/log, and I went along with that since it was years ago and I was a n00b and didn't know any better. /var/lib/pkgtools will be a better and safer location. The removed_packages and removed_scripts directories are really just logs that aren't actually used for anything - those will remain under /var/log, but moved into /var/log/pkgtools. Everything under /var/log will be considered potentially non-permanent by the pkgtools - if any directories or symlinks disappear from there, the pkgtools will automatically recreate them as needed. In fact, the migration process will create symlinks from all the old directory locations to the new ones, so anything that expects the old locations (including slackpkg, for now) should continue to work. Once this moves into the main tree, the plan is to fix other packages to use the new installer script directory (/var/lib/pkgtools/setup) and change the installer and slackpkg to use the new native locations for everything. When slackpkg is changed over to use the new native locations, I'll also make sure to float that in testing/ for a few days before moving it to the main tree to avoid more unintentional disruption to slackpkg+ users. Be aware that the package database migration is a one-way operation, but even so if you later downgrade to an older version of the pkgtools it will still work through the compatibility symlinks.

Added note: In retrospect I wonder if an upgradepkg --reinstall pkgtools might not have done the trick?