Hello everybody!

I've been away for a while. It's not for lack of Slackware use--I've
been as active as ever.

What brings me back is a question:

How are /var/log/packages and /var/log/removed_packages affected by
use of the usual upgrade drill:

slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system

I understand that this drill installs, upgrades, and removes
packages as needed to give a new set of packages which includes only
those that currently belong to a standard Slackware installation,
and it upgrades all of them to the version in the official Slackware
tree.

My question, specifically, is what does this drill do to dirs
/var/log/packages and /var/log/removed_packages? I'm guessing that
it:

-Deletes files as needed so that /var/log/packages shows only the
packages that are currently installed.

-Deletes and re-makes corresponding files of /var/log/packages
when packages are upgraded.

-Adds new files to var/log/removed_packages to reflect removal of
packages.

-Deletes and re-makes corresponding files of
/var/log/removed_packages when packages that have already been
removed are installed and removed again.

I will try to figure this out?the next time I use the drill, but I
thought I would post the question here to see what all of you think.

Does anyone have an opinion on this?

I'm thinking about this, because I would like a way that I can learn
the history of the package installs and removals. It seems, if the
above is true, that I should manually copy /var/log/packages and
/var/log/removed_packages to someplace (perhaps giving them new names
which reflect the date) every time I use the drill.

Thanks to all of you!

-Joe

On Tue, 01 Jun 2021 02:34:06 +0000, Joe Rosevear wrote:
> How are /var/log/packages and /var/log/removed_packages affected by
> use of the usual upgrade drill:

I have not used slackpkg, (usually I use installpkg, upgradepkg and slpkg
instead) but in Slackware stable /var/log/packages reflects your
installed packages and /var/log/removed_packages shows the history of
removed packages. If you use upgradepkg the file names in
removed_packages will also get a timestamp, something like this:

wget-1.19.4-x86_64-1_slack14.2-upgraded-2019-06-07,10:55:52

> I'm thinking about this, because I would like a way that I can learn the
> history of the package installs and removals. It seems, if the above is
> true, that I should manually copy /var/log/packages and
> /var/log/removed_packages to someplace (perhaps giving them new names
> which reflect the date) every time I use the drill.

I don't see a big need for copying those directories as the history is
already there. However, if you really do, you might also want to consider
the directories /var/log/scripts/ and /var/log/removed_scripts/ which
contains each packages /install/doinst.sh renamed to the package name and
possibly with a timestamp in the filename in /var/log/removed_scripts.

regards Henrik

Thank you, Henrik, for your reply.

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Tue, 01 Jun 2021 02:34:06 +0000, Joe Rosevear wrote:
>> How are /var/log/packages and /var/log/removed_packages affected by
>> use of the usual upgrade drill:
>
> I have not used slackpkg, (usually I use installpkg, upgradepkg and slpkg
> instead) but in Slackware stable /var/log/packages reflects your
> installed packages

Aha!

> and /var/log/removed_packages shows the history of
> removed packages. If you use upgradepkg the file names in
> removed_packages will also get a timestamp, something like this:
>
> wget-1.19.4-x86_64-1_slack14.2-upgraded-2019-06-07,10:55:52

Ah! It seems that multiple removals of the same package (with
intervening installs, of course) would generate multiple entries. That
sounds like what I needed. But I wonder, does
/var/log/removed_packages keep growing indefinitely? Of course,
deleting or moving and remaking the file would cause it to start over?

>> I'm thinking about this, because I would like a way that I can learn the
>> history of the package installs and removals. It seems, if the above is
>> true, that I should manually copy /var/log/packages and
>> /var/log/removed_packages to someplace (perhaps giving them new names
>> which reflect the date) every time I use the drill.
>
> I don't see a big need for copying those directories as the history is
> already there.

Based on what you wrote, I agree with you.

> However, if you really do, you might also want to consider
> the directories /var/log/scripts/ and /var/log/removed_scripts/ which
> contains each packages /install/doinst.sh renamed to the package name and
> possibly with a timestamp in the filename in /var/log/removed_scripts.

Right. I thought someone might say that. I intentionally avoided
mention of those two directories to simplify my question. Let me ask:
Do they behave in the same way as the corresponding package
directories?

> regards Henrik

Hey, thanks for mentioning slpkg. I looked it up on Slackbuilds.org,
and I am intrigued. It's a system that manages dependancies for a
distrubution that is known for its lack of dependancy management. What
about "dependancy hell"? I assume it works well for you or you
wouldn't use it.

-Joe

Joe Rosevear <Joe_Rosevear@localhost.invalid> wrote:
> Hey, thanks for mentioning slpkg. I looked it up on Slackbuilds.org,
> and I am intrigued. It's a system that manages dependancies for a
> distrubution that is known for its lack of dependancy management. What
> about "dependancy hell"? I assume it works well for you or you
> wouldn't use it.
>
> -Joe

I run 14.2.

I have used slpkg for some time without any problems. Recently, however,
I found a problem. I use calibre to reformat books. I tried to
convert a mobi file into an epub and the conversion hung. I pulled down
a more recent version of calbre from slonly. Along the way a number
of packages were updated and the result was that the new calibre didn't
work at all. I tried to rebuild calibre from SBO and that failed after
running overnight. I finally restored my system from backup.

The problem with slpkg is that the config files which were used to
build the packages at the repository might not correspond to your
current system.

If you do use slpkg always use update first:

slpkg update

Then use the -F option to find a repository

slpkg -F package

finally use that repository to fetch the package:

slpkg -s repository package

On Wed, 02 Jun 2021 05:44:27 +0000, Joe Rosevear wrote:

> Thank you, Henrik, for your reply.
>
> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> and /var/log/removed_packages shows the history of removed packages. If
>> you use upgradepkg the file names in removed_packages will also get a
>> timestamp, something like this:
>>
>> wget-1.19.4-x86_64-1_slack14.2-upgraded-2019-06-07,10:55:52
>
> Ah! It seems that multiple removals of the same package (with
> intervening installs, of course) would generate multiple entries. That
> sounds like what I needed. But I wonder, does /var/log/removed_packages
> keep growing indefinitely? Of course, deleting or moving and remaking
> the file would cause it to start over?

I don't think that I have ever upgraded or removed the same version of a
package twice so I cant say for sure. But my guess would be like yours
that you will get multiple files with different time stamps in their name.

slpkg might be a different story, it seems as if at least some of the
files in /var/removed_packages upgraded by slpkg misses the time stamp in
the file name on my computer. I don't think that is a big deal as the
files still have their timestamps as metadata.

In theory removed_packages grows indefinitely, but in practice it does
not grow very big. I have 299 files in my directory and it is only 17 MB
big.

Maybe I should add as a disclaimer that I am no expert of that directory,
I have never really used it for anything useful, I have only noted that
it is there and seen what is in it.
> Hey, thanks for mentioning slpkg. I looked it up on Slackbuilds.org,
> and I am intrigued. It's a system that manages dependancies for a
> distrubution that is known for its lack of dependancy management. What
> about "dependancy hell"? I assume it works well for you or you wouldn't
> use it.

Yes, that is exactly the big usefullness of slpkg. I use it to install
packages from slackbuilds.org which slpkg then builds from source and
handles all dependencies. It will ask you before upgrading any existing
packages and if you don't want it to upgrade dependencies you can use the
switch --resolve-off. When all dependencies are new packages I let slpkg
install them. When some dependencies want to upgrade existing packages I
usually avoid upgrading with --resolve-off to avoid getting other
installed packages broken.

regards Henrik