upgrade package and any needed libraries

[John Forkosh]

How do you use slackpkg to upgrade a package along with
any libraries that the upgraded package may also need?
In particular, I have a three-year-old -current64
from November 2021 installed, which is using firefox 91.3.
But now, when started, firefox says some features may stop
working January 15, 2025, and "volunteers" to upgrade for me.
But I'm concerned that the upgraded firefox may also
need some libraries upgraded, and that it won't work if
I just let mozilla automatically upgrade firefox for me.
But I'm also not seeing how to identify and upgrade
any such needed libraries with slackpkg (and haven't
been able to google -options to do that).

And finally, if I identify and upgrade those libraries
along with firefox, what about any other older installed
packages that still need the older libraries? Is there
a way to keep both the newer libraries for firefox,
and the older versions for everything else?
From what very little I know, the installed libraries
are usually "addressed" by symlinks library-->library.version,
so both old and new libraries could co-exist, but programs
using them would only see the version pointed to by the
symlink. Is that right? How could I deal with that?
Thanks.

[John Forkosh]

Post by John Forkosh
How do you use slackpkg to upgrade a package along with
any libraries that the upgraded package may also need?
In particular, I have a three-year-old -current64
from November 2021 installed, which is using firefox 91.3.
But now, when started, firefox says some features may stop
working January 15, 2025, and "volunteers" to upgrade for me.
But I'm concerned that the upgraded firefox may also
need some libraries upgraded, and that it won't work if
I just let mozilla automatically upgrade firefox for me.
But I'm also not seeing how to identify and upgrade
any such needed libraries with slackpkg (and haven't
been able to google -options to do that).
And finally, if I identify and upgrade those libraries
along with firefox, what about any other older installed
packages that still need the older libraries? Is there
a way to keep both the newer libraries for firefox,
and the older versions for everything else?
From what very little I know, the installed libraries
are usually "addressed" by symlinks library-->library.version,
so both old and new libraries could co-exist, but programs
using them would only see the version pointed to by the
symlink. Is that right? How could I deal with that?
Thanks.

Apparently no problem. Firefox seems to come equipped with
all the libraries it needs and uses. And which firefox points
to /usr/bin/firefox which is just a short shell script that runs
exec /usr/lib64/firefox/firefox "$@"

So I downloaded firefox-132.0.tar.bz2 from
https://www.mozilla.org/en-US/firefox/linux/
and then extracted its firefox/ directory and renamed/moved it
with mv firefox /usr/lib64/firefox-browser-132.0
Then I cd'd to /usr/lib64/ and renamed the installed 91.3.0
version with mv firefox firefox-browser-91.3.0
Finally, symlinked ln -s firefox-browser-132.0/ firefox
so the shell script would run 132.0, but keeping the old
91.3.0 version just in case. Seems to be running flawlessly
so far (which is ~15 minutes).

Not sure what would have happened if I'd just used slackpkg to
install the latest slackware firefox package.

[Sam]

Post by John Forkosh
How do you use slackpkg to upgrade a package along with
any libraries that the upgraded package may also need?

I'm not aware of any Slackware tool for this. I think that this is
Slackware's biggest technical disadvantage: lack of package dependency
tracking. Both dpkg and rpm handle that automatically. dpkg and rpm were
doing everything that you described in your post, for a couple of decades
now…

Slackware simply does not have any kind of inherent dependency tracking
between packages. The usual response when this gets pointed out is: well,
Slackware installs everything in one fell swoop so this isn't needed. And
this is true: as long as you only need to run what's packaged by Slackware,
you don't need this kind of dependency tracking. If you need to be based on
a distribution that you can customize with custom or updated packages,
without everything falling apart, you'll need to look elsewhere.

[John Forkosh]

Post by Sam

Post by John Forkosh
How do you use slackpkg to upgrade a package along with
any libraries that the upgraded package may also need?

I'm not aware of any Slackware tool for this. I think that this is
Slackware's biggest technical disadvantage: lack of package dependency
tracking. Both dpkg and rpm handle that automatically. dpkg and rpm were
doing everything that you described in your post, for a couple of decades
now?
Slackware simply does not have any kind of inherent dependency tracking
between packages. The usual response when this gets pointed out is: well,
Slackware installs everything in one fell swoop so this isn't needed. And
this is true: as long as you only need to run what's packaged by Slackware,
you don't need this kind of dependency tracking. If you need to be based on
a distribution that you can customize with custom or updated packages,
without everything falling apart, you'll need to look elsewhere.

Thanks for the additional information, Sam. Too bad. I'd of thunk
that PV and other slack maintainers could've migrated these kinds
of capabilities from other linux distros without too much trouble.
Maybe slack16. Anyway, I'm otherwise usually very happy with slack,
so am not yet tempted to "look elsewhere".

[Sam]

Post by John Forkosh
Thanks for the additional information, Sam. Too bad. I'd of thunk
that PV and other slack maintainers could've migrated these kinds
of capabilities from other linux distros without too much trouble.

There's much more to this than meets the eye. Much, much more. Dependency
tracking is a complicated, complex task. Even decades later, rpm and dpkg
are still tweaking their algorithms and features. Just a short while ago
Canonical turned off updates to noble because of a dependency issue:

https://www.omgubuntu.co.uk/2024/09/canonical-halts-ubuntu-24-04-lts-upgrades-again

Post by John Forkosh
Maybe slack16. Anyway, I'm otherwise usually very happy with slack,
so am not yet tempted to "look elsewhere".

Well, this is not something new. Dependency tracking between packages of a
Linux distributoin was a known bullet point for a very, very long time. If
Slackware did not gain /any/ kind of dependency tracking by now – even just
between shared libraries (rpm also tracks dependencies of Perl, Python, and
Java modules) – then the chances of that popping up in the near future, I
don't see to be very likely…

[W. Greenhouse]

Post by John Forkosh
Thanks for the additional information, Sam. Too bad. I'd of thunk
that PV and other slack maintainers could've migrated these kinds
of capabilities from other linux distros without too much trouble.
Maybe slack16. Anyway, I'm otherwise usually very happy with slack,
so am not yet tempted to "look elsewhere".

What is the usecase for a partial slackpkg update? On a release of
Slackware, you should upgrade-all because the only stuff that happens is
basically security updates and other bug fixes once a release is
finalized. On -current you should install-new and upgrade-all because
the whole dependency structure may be in flux (you're sitting on the
staging area for the next release).

So PV didn't solve this problem because it did not yet need to be solved.

[Eric Pozharski]

*SKIP* [ 5 lines 2 levels deep] # redhat propaganda blob

Post by W. Greenhouse
What is the usecase for a partial slackpkg update?

Correction: it's not "partial slackpkg update", it is "unsupported
Slackware".

Usecase: EEE-PC. Thing just have no space for full install.

*SKIP* [ 6 lines 1 level deep]

Post by W. Greenhouse
So PV didn't solve this problem because it did not yet need to be solved.

This problem isn't solved because there's no problem to solve.

[Sylvain Robitaille]

Post by Eric Pozharski
Usecase: EEE-PC. Thing just have no space for full install.

+1 on that, and on Henrik Carlqvist's recommendation that the OP
upgrade his system to stable Slackware-15.0 and keep up with patches
on that syetm.

Further to Eric's point, another condition that folks who advocate
"just do a full install and don't worry about it" overlook is that
for some systems, a full install simply isn't appropriate. I have
a system, for example, whose primary purpose in life is to provide
services (mail/DNS/web) to systems outside of my home network.
There is a lot of software included in a Slackware full installation
that it simply wouldn't make sense to install on that system.
Another system acts as a gateway system for my home network to the
outside world, (well, to the ISP anyway). What's appropriate for it is
a *different* subset of a full installation than the former system has.
Still different yet, the web server on the former system runs in a
chroot environment which is itself mostly a smaller subset of what's
installed on that system (plus some additional packages needed just
for the web server).

Bottom line is that a full-installation of any Linux distribution
simply isn't always appropriate. In fact, I would go so far as to
say it seldomly *is* appropriate, but if one keeps up with patches,
including for the unused software packages, it's probably mostly
harmless (on a single-user desktop or laptop system).

I wrote a script, many years ago, that helps me identify which other
packages a given installed package depends on, so that if I'm having
trouble with software on a system with a not-full installation,
I can compare to the same software on a more complete installation
and see what might be missing.

https://www.therockgarden.ca/software/slackware/listdeps.sh

I hope that helps somebody.

[Alexander Grotewohl]

Post by Eric Pozharski
Usecase: EEE-PC. Thing just have no space for full install.

+1 on that, and on Henrik Carlqvist's recommendation that the OP upgrade
his system to stable Slackware-15.0 and keep up with patches on that
syetm.
Further to Eric's point, another condition that folks who advocate "just
do a full install and don't worry about it" overlook is that for some
systems, a full install simply isn't appropriate. I have a system, for

sorry, still don't agree.

even in your proposed usecase things like PHP's image support with GD
will dip into the X package set for image handling.

your script misses this entirely.

[Sylvain Robitaille]

Post by Alexander Grotewohl

... another condition that folks who advocate "just do a full install
and don't worry about it" overlook is that for some systems, a full
install simply isn't appropriate. ...

sorry, still don't agree.

Agree with it or not, I've been doing it this way for decades and my
systems have the functionality that they need. Not one (including
desktop and laptop systems) has a full installation. They don't
need it. but the desktops and laptops do come closest.

Post by Alexander Grotewohl
even in your proposed usecase things like PHP's image support with GD
will dip into the X package set for image handling.
your script misses this entirely.

The script misses that, because that's not what it's intended for.

PHP's image support, (if I needed that), does not need the entire X
subset.

[Gamgee]

To: Sylvain Robitaille
-=> Sylvain Robitaille wrote to alt.os.linux.slackware <=-

Post by Alexander Grotewohl

... another condition that folks who advocate "just do a full install
and don't worry about it" overlook is that for some systems, a full
install simply isn't appropriate. ...

sorry, still don't agree.

SR> Agree with it or not, I've been doing it this way for decades and my
SR> systems have the functionality that they need. Not one (including
SR> desktop and laptop systems) has a full installation. They don't
SR> need it. but the desktops and laptops do come closest.

I also don't ever do a full install, at least by my definition. What I
mean is that I never include the emacs, KDE, or Tex categories, but
usually everything else.

Post by Alexander Grotewohl
even in your proposed usecase things like PHP's image support with GD
will dip into the X package set for image handling.
your script misses this entirely.

SR> The script misses that, because that's not what it's intended for.

I haven't kept up with (and can't at this time go back and look) the
prior conversation in this thread, but wondering if this script you're
talking about does something similar to what I said above; or is more
fine-grained than that and does more detailed "filtering" of what gets
installed...



--- MultiMail/Linux v0.52
--- Synchronet 3.20a-Linux NewsLink 1.114
Palantir BBS - telnet://palantirbbs.ddns.net

[Sylvain Robitaille]

Post by Gamgee

Post by Alexander Grotewohl
even in your proposed usecase things like PHP's image support with GD
will dip into the X package set for image handling.
your script misses this entirely.

SR> The script misses that, because that's not what it's intended for.
I haven't kept up with (and can't at this time go back and look) the
prior conversation in this thread, but wondering if this script you're
talking about does something similar to what I said above; or is more
fine-grained than that and does more detailed "filtering" of what gets
installed...

Nothing of the sort. This script attempts to list what packages a given
installed package depends on. For example ...

If I want to install (for example) amanda (the backup software, of
which I have a locally created package installed) on a system with an
otherwise minimal install, I would need to ensure that the following
packages are also installed:

: hecate[syl] ~; src/slackware/listdeps.sh amanda
aaa_libraries-15.0-x86_64-19
amanda-3.3.9-x86_64-1
brotli-1.0.9-x86_64-7
c-ares-1.19.1-x86_64-1_slack15.0
curl-8.10.1-x86_64-1_slack15.0
cyrus-sasl-2.1.28-x86_64-1_slack15.0
e2fsprogs-1.46.5-x86_64-1
flex-2.6.4-x86_64-5
glib2-2.70.3-x86_64-1
keyutils-1.6.3-x86_64-3
libffi-3.3-x86_64-3
libidn2-2.3.2-x86_64-1
libnsl-1.3.0-x86_64-3
libpsl-0.21.1-x86_64-4
libssh2-1.11.1-x86_64-1_slack15.0
libtirpc-1.3.2-x86_64-1
libunistring-0.9.10-x86_64-3
nghttp2-1.61.0-x86_64-1_slack15.0
openssl-1.1.1zb-x86_64-1_slack15.0
openssl-solibs-1.1.1zb-x86_64-1_slack15.0
pcre-8.45-x86_64-1
readline-8.1.002-x86_64-1
zlib-1.2.13-x86_64-1_slack15.0
zstd-1.5.5-x86_64-1_slack15.0

(that's probably all indeed installed on my hypothetical minimal
installation system anyway, but I hope that it illustrates the purpose
and use of my script. It's not so much dependency *tracking*, as it is
dependency listing ...)

[Gamgee]

To: Sylvain Robitaille
-=> Sylvain Robitaille wrote to alt.os.linux.slackware <=-

Post by Gamgee
I haven't kept up with (and can't at this time go back and look) the
prior conversation in this thread, but wondering if this script you're
talking about does something similar to what I said above; or is more
fine-grained than that and does more detailed "filtering" of what gets
installed...

SR> Nothing of the sort. This script attempts to list what packages a
SR> given installed package depends on. For example ...

SR> If I want to install (for example) amanda (the backup software, of
SR> which I have a locally created package installed) on a system with an
SR> otherwise minimal install, I would need to ensure that the following
SR> packages are also installed:

SR> : hecate[syl] ~; src/slackware/listdeps.sh amanda
SR> aaa_libraries-15.0-x86_64-19
SR> amanda-3.3.9-x86_64-1
SR> brotli-1.0.9-x86_64-7
SR> c-ares-1.19.1-x86_64-1_slack15.0
SR> curl-8.10.1-x86_64-1_slack15.0
SR> cyrus-sasl-2.1.28-x86_64-1_slack15.0
SR> e2fsprogs-1.46.5-x86_64-1
SR> flex-2.6.4-x86_64-5
SR> glib2-2.70.3-x86_64-1
SR> keyutils-1.6.3-x86_64-3
SR> libffi-3.3-x86_64-3
SR> libidn2-2.3.2-x86_64-1
SR> libnsl-1.3.0-x86_64-3
SR> libpsl-0.21.1-x86_64-4
SR> libssh2-1.11.1-x86_64-1_slack15.0
SR> libtirpc-1.3.2-x86_64-1
SR> libunistring-0.9.10-x86_64-3
SR> nghttp2-1.61.0-x86_64-1_slack15.0
SR> openssl-1.1.1zb-x86_64-1_slack15.0
SR> openssl-solibs-1.1.1zb-x86_64-1_slack15.0
SR> pcre-8.45-x86_64-1
SR> readline-8.1.002-x86_64-1
SR> zlib-1.2.13-x86_64-1_slack15.0
SR> zstd-1.5.5-x86_64-1_slack15.0

SR> (that's probably all indeed installed on my hypothetical minimal
SR> installation system anyway, but I hope that it illustrates the purpose
SR> and use of my script. It's not so much dependency *tracking*, as it is
SR> dependency listing ...)

Ahhhh, OK. Very nice, indeed; well done.



--- MultiMail/Linux v0.52
--- Synchronet 3.20a-Linux NewsLink 1.114
Palantir BBS - telnet://palantirbbs.ddns.net

[Joseph Rosevear]

On Tue, 12 Nov 2024 21:06:37 GMT, Sylvain Robitaille wrote:

[snip]

Post by Sylvain Robitaille
I wrote a script, many years ago, that helps me identify which other
packages a given installed package depends on, so that if I'm having
trouble with software on a system with a not-full installation,
I can compare to the same software on a more complete installation and
see what might be missing.
https://www.therockgarden.ca/software/slackware/listdeps.sh
I hope that helps somebody.

Hello,

I browsed your therockgarden.ca website, very nice! Thanks for providing
the link. I was attracted to it by the mention of listdeps.sh that you
made above. People should write collections of code, yes? It's a duty,
I think.

I had a job once managing a collection of code on *nix and other
machines. I'm afraid it permanently affected me. I can't let it go--I
just keep writing code. Almost entirely Bash. A very little C and
Python thrown in. And some PHP when I have to. That came later.
Originally it was Fortran and shell code. That was a long time ago.

So back to this duty we have. If I find I like your listdeps.sh may I
stick it in my collection? It may end up eventually published in a
library for my SAM system. I will give you credit as the author, but
would like to change the name of listdeps.sh, dropping the suffix.

I have found tools are easier to use when they are treated as commands.
My SAM system allows any directory of commands, including certain
function definitions, to be used as a menu or as a library--thus enabling
the writing of code which supports other code.

I hope that you are thinking that someone should have done this a long
time ago! Well, like I said, I've been working on this for a while.

You can read about my SAM at RosevearSoftware.com and about me at
JoesLife.org.

-Joe

[Sylvain Robitaille]

Post by Joseph Rosevear
I browsed your therockgarden.ca website, very nice!

Well thank you. Development on the website itself is rather glacially
slow, I'm afraid, but the site is there for those that might find
something useful from it.

Post by Joseph Rosevear
People should write collections of code, yes? It's a duty, I think.

Well, when I write something that I imagine might be useful to others,
I make it available. There's plenty that I've written that I wouldn't
expect anyone to even notice, let alone care about. I don't feel any
"duty" to create code; I do think that there's value in sharing what
I've done, though I do apply judgement to determine what might be
worth sharing.

Post by Joseph Rosevear
I had a job once managing a collection of code on *nix and other
machines.

My job was never actually about coding or managing code, but rather
about managing (Unix and Linux) systems themselves. The coding, of
course, is simply a tool that facilitates that.

Post by Joseph Rosevear
... If I find I like your listdeps.sh may I stick it in my collection?

Yes. I place no restriction on code I've made available, other than to
ask that I get credit for my work.

Post by Joseph Rosevear
... would like to change the name of listdeps.sh, dropping the suffix.

There's nothing wrong with doing that.

Post by Joseph Rosevear
I have found tools are easier to use when they are treated as commands.

I tend to think, more than anything, of the Unix "pipeline" method of
building tools. The best tools are those that I can use to build other
tools with.

Thanks for looking at my site, and for seeking permission to include my
script in your project.

[Sasha]

Post by Sam

How do you use slackpkg to upgrade a package along with any libraries
that the upgraded package may also need?

I'm not aware of any Slackware tool for this. I think that this is
Slackware's biggest technical disadvantage: lack of package dependency
tracking. Both dpkg and rpm handle that automatically. dpkg and rpm
were doing everything that you described in your post, for a couple of
decades now?
Slackware simply does not have any kind of inherent dependency tracking
well, Slackware installs everything in one fell swoop so this isn't
needed. And this is true: as long as you only need to run what's
packaged by Slackware,
you don't need this kind of dependency tracking. If you need to be
based on a distribution that you can customize with custom or updated
packages, without everything falling apart, you'll need to look
elsewhere.

Thanks for the additional information, Sam. Too bad. I'd of thunk that
PV and other slack maintainers could've migrated these kinds of
capabilities from other linux distros without too much trouble. Maybe
slack16. Anyway, I'm otherwise usually very happy with slack,
so am not yet tempted to "look elsewhere".

You can actually use Salix's dependency resolution in Slackware. You have
to install slapt-get and point it to one of Salix's mirrors of the
slackware-15.0/ folder, which has an extra "deps" folder. Then you get
dependency resolution for all the standard Slackware packages.

[Henrik Carlqvist]

I have a three-year-old -current64 from November 2021 installed, which
is using firefox 91.3.

Why? There are Slackware stable releases and there is Slackware current.

Some people describe Slackware current as a rolling release, some people
describe Slackware current as a alpha release of the upcoming stable
release and a moving target.

In February 2022 stable version Slackware 15.0 was released from the then
latest status of the current branch. Looking at the ChangeLog.txt for
mozilla-firefox between November 2021 and Februari 2022 we find:

+--------------------------+
Thu Jan 27 22:43:13 UTC 2022
xap/mozilla-firefox-91.5.1esr-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.mozilla.org/en-US/firefox/91.5.1/releasenotes/
(* Security fix *)

+--------------------------+
Wed Jan 12 22:04:33 UTC 2022
xap/mozilla-firefox-91.5.0esr-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/firefox/91.5.0/releasenotes/
https://www.mozilla.org/security/advisories/mfsa2022-02/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22746
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22743
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22742
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22741
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22740
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22738
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22737
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4140
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22748
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22745
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22744
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22747
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22739
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22751
(* Security fix *)

+--------------------------+
Thu Dec 16 21:34:10 UTC 2021
xap/mozilla-firefox-91.4.1esr-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.mozilla.org/en-US/firefox/91.4.1/releasenotes/

+--------------------------+
Tue Dec 7 21:02:41 UTC 2021
xap/mozilla-firefox-91.4.0esr-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/firefox/91.4.0/releasenotes/
https://www.mozilla.org/security/advisories/mfsa2021-53/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43536
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43537
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43538
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43539
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43541
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43542
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43543
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43545
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43546
https://bugzilla.mozilla.org/show_bug.cgi?id=1737751
(* Security fix *)

But now, when started, firefox says some features may stop working

By sticking to that old version of Firefox you expose yourself to a
number of well known security issues in Firefox. By sticking to a
snapshot of Slackware current from 2021 you expose a number of other
applications to known security issues.

I can understand if you don't want to live on the bleeding edge and keep
Slackware current updated, but if so, stable Slackware 15.0 would be a
much better choice for you. However, even running a stable version of
Slackware does not mean that you don't have to install any updates. There
are also security updates for maintained stable version of Slackware and
Mozilla Firefox usually get rather frequent updates.

In another message you wrote that your solution was to install a binary
blob from Mozilla with a newer version of Firefox. That solution has
solved security issues with Firefox at the cost of not being able to
maintain Firefox with Slackware package management tools. But still you
have the problems with all those other security updates for Slackware
which you haven't installed.

I think that the best solution for you would be to upgrade to Slackware
15.0 and keep that 15.0 installation updated with all security patches.
Updates to stable versions of Slackware are less likely to break anything
compared to updates of current.

regards Henrik

[Marco Moock]

Post by John Forkosh
How do you use slackpkg to upgrade a package along with
any libraries that the upgraded package may also need?

The only way is manual with trial and error.

Although, I highly recommend upgrading all packages, not only for
security reasons.

You can use slackpkg upgrade-all to achieve that.

[Joseph Rosevear]

How do you use slackpkg to upgrade a package along with any libraries
that the upgraded package may also need?

[snip]

OK, I'm going to jump into this thread. There has been some good advice
given, but here are my two cents:

I don't do what you are doing. Instead I update my whole Slackware
installation. No mess no fuss. Three lines entered in xterm does it:

/mnt/joe_root/begin
bound $lib/Zombie
up_basis

I showed you the above to demonstrate how simple it is with the right
tools. The "begin", "bound" and "up_basis" tools are mine. "begin"
starts my menu system--I keep it on a flash drive. "bound $lib/Zombie"
goes to the Zombie menu which contains the "up_basis" script. "up_basis"
runs:

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

Be careful if you use the above. "slackpkg clean-system" is a great
command, because it shows you what additional Slackware packages you have
added, but it will optionally also remove them.

Maybe do a backup before you run the above--just in case it breaks
something.

I run "up_basis", but not on my daily system. Instead I run it on a
special "Basis" system which lives on an internal drive. Then, if it
looks OK, I run another command in the Zombie menu to rsync the Basis to
a different device and then tweak it:

install /dev/sda1 /dev/sde 1 2 3 191026aa

I call the resulting "tweaked" installation ZombieSlack. I'll stop here
and not tell you the rest of the story. I wanted to show you how simple
it can be with the right tools.

-Joe

[John Forkosh]

Post by Joseph Rosevear

How do you use slackpkg to upgrade a package along with any libraries
that the upgraded package may also need?

[snip]
OK, I'm going to jump into this thread. There has been some good advice
I don't do what you are doing. Instead I update my whole Slackware
/mnt/joe_root/begin
bound $lib/Zombie
up_basis
I showed you the above to demonstrate how simple it is with the right
tools. The "begin", "bound" and "up_basis" tools are mine. "begin"
starts my menu system--I keep it on a flash drive. "bound $lib/Zombie"
goes to the Zombie menu which contains the "up_basis" script. "up_basis"
slackpkg update gpg
slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system
Be careful if you use the above. "slackpkg clean-system" is a great
command, because it shows you what additional Slackware packages you have
added, but it will optionally also remove them.
Maybe do a backup before you run the above--just in case it breaks
something.
I run "up_basis", but not on my daily system. Instead I run it on a
special "Basis" system which lives on an internal drive. Then, if it
looks OK, I run another command in the Zombie menu to rsync the Basis to
install /dev/sda1 /dev/sde 1 2 3 191026aa
I call the resulting "tweaked" installation ZombieSlack. I'll stop here
and not tell you the rest of the story. I wanted to show you how simple
it can be with the right tools.
-Joe

Thanks for all the additional information, Joe and everybody.
On each of my several desktop boxes, I usually keep four slackware
partitions on a 1TB ssd that's /dev/sda, and all data on a much
larger hdd on /dev/sdb (with /home symlinked to a similar home on sdb).
Then I rotate through the four slackwares when updating, keeping
the older ones just in case. So I can try your update procedure
on one of those older installs, without too much worry.

But my usual "update" procedure is just a whole new install. I usually
rsync -av --delete \
rsync://mirrors.kernel.org/slackware/slackware64-current/ \
empty_slackware_directory/
and then run usbimg2disk.sh to make a bootable usb stick,
from which I do a clean install on the next sda partition in the
rotation. Then I do lots of additional stuff, e.g., on an older
box, add pci=nommconf to kernel options append= line in lilo.conf or
elilo.conf to avoid tons of "PCIe Bus Error"s as soon as dhcpcd starts.

[Henrik Carlqvist]

Post by Joseph Rosevear
slackpkg update gpg
slackpkg update
slackpkg install-new
slackpkg upgrade-all
slackpkg clean-system

Care should be taken when running any such automated process that some
packages might require extra manual intervention.

Some packages will contain some /etc/*.new configuration file which does
not overwrite any existing configuration file, but might be better
adapted to the new version of the software.

Whenever the kernel is updated there is a big fat warning in
ChangeLog.txt about the importance of updating your boot loader. Failing
to do so might result in a system which doesn't boot or a system which
boots a kernel unable to find any matching kernel modules.

regards Henrik

[Joseph Rosevear]

Post by Henrik Carlqvist

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

Care should be taken when running any such automated process that some
packages might require extra manual intervention.
Some packages will contain some /etc/*.new configuration file which does
not overwrite any existing configuration file, but might be better
adapted to the new version of the software.

[snip]

Post by Henrik Carlqvist
regards Henrik

Hello, Henrik! Thanks for your comments.

Are you talking about the "K", "O", "R", "P" question that I've seen? I
don't get that every time--perhaps only when the kernel is updated?.
Anyway, it is a bothersome question. I always choose "O". I don't think
I want to wade through all of them--which is an option--I don't remember
which.

So far the process I described has worked for me, but then I've only been
updating/upgrading regularly for a few months now. I'll holler, if I
have trouble. It's nice to know there is help here in this Usenet group.

I must say, though, that currently I'm happy, My tools make it easy, and
as a result I'm able to update/upgrade often.

This is in contrast to what I did before. I was bad. I often went
several years between, because the way I applied my system tweaks made it
difficult. But no more! I hope I'm not naive.

-Joe

[John Forkosh]

<<snip>>
This is in contrast to what I did before. I was bad.
I often went several years between, because the way
I applied my system tweaks made it difficult.

That's still me, to a tee.

But no more! I hope I'm not naive.

And I'm still striving to achieve naive.

[Henrik Carlqvist]

Post by Joseph Rosevear
Are you talking about the "K", "O", "R", "P" question that I've seen?

I must admit that I am not very familiar with slackpkg myself. I install
my security update with a custom Makefile which basically just checks
that it is run on the right Slackware version (by checking
/etc/slackware-version) before running
"upgradepkg --install-new --reinstall" on all packages that need to get
updated. I have customized my kernel packages, they contain my own,
possibly patched kernels and the doinst.sh also checks which bootloader
is being used and updates that. But probably most important, I carefully
read the ChangeLog.txt before downloading and installing any packages.

Nevertheless I have hit some bumps during the years. At some occasion
some glibc-zoneinfo package reseted all my time zone settings. Since then
I avoid upgrading such packages. If we would switch to another time zone
or change the daylight saving dates in Sweden I would probably have to
upgrade that package. I usually also first install the updates on a test
system and try to see if the behave as expected before pushing them out
to more systems.

Post by Joseph Rosevear
So far the process I described has worked for me, but then I've only
been updating/upgrading regularly for a few months now.

Fortunately, kernel updates in stable versions of Slackware does not
happen very often. The last such update was back in June 2024 when the
kernel was upgraded to 5.15.161.

regards Henrik

[Rich]

Post by Henrik Carlqvist
Nevertheless I have hit some bumps during the years. At some occasion
some glibc-zoneinfo package reseted all my time zone settings.

Your system timezone is set via a symlink (usually) at /etc/localtime
which points to the appropriate zone file stored in /usr/share/zoneinfo
(Slack 15).

Perhaps the package that mucked things up changed that symlink for you.

[jayjwa]

Post by Rich
Your system timezone is set via a symlink (usually) at /etc/localtime
which points to the appropriate zone file stored in /usr/share/zoneinfo
(Slack 15).

Don't quote me on this, but I think a long time ago, Slackware used to
use a file instead of the symlink. glibc advises the symlink. At some
point it switched over. There's been alot of major changes over the
years for Slackware (PAM and Avahi come to mind).

[Rich]

Post by jayjwa

Post by Rich
Your system timezone is set via a symlink (usually) at /etc/localtime
which points to the appropriate zone file stored in /usr/share/zoneinfo
(Slack 15).

Don't quote me on this, but I think a long time ago, Slackware used to
use a file instead of the symlink. glibc advises the symlink. At some
point it switched over. There's been alot of major changes over the
years for Slackware (PAM and Avahi come to mind).

If you go back in time far enough, yes, the Slackware installer did a
"cp /usr/share/zoneinfo/xx/yyy /etc/localtime" to set your timezone.

I don't recall what version made the switch to the symlink.

[Henrik Carlqvist]

Post by Rich
If you go back in time far enough, yes, the Slackware installer did a
"cp /usr/share/zoneinfo/xx/yyy /etc/localtime" to set your timezone.
I don't recall what version made the switch to the symlink.

I don't remember for sure which version of Slackware got the timezone
setting reseted by a package upgrade, maybe it was Slackware 9.1 or
somewhere around that era.

Looking at the doinst.sh for the glibc-zoneinfo-2011i_2011n-noarch-1.tg
for Slackware 9.1 it does seem to use symlinks, but seem to mess with
etc/localtime unless etc/localtime-copied-from already exist and that
file (or link) does not seem to be created by the original
glibc-zoneinfo-2.3.2-noarch-1.tgz for Slackware 9.1.

regards Henrik

[Rich]

Post by Henrik Carlqvist

Post by Rich
If you go back in time far enough, yes, the Slackware installer did a
"cp /usr/share/zoneinfo/xx/yyy /etc/localtime" to set your timezone.
I don't recall what version made the switch to the symlink.

I don't remember for sure which version of Slackware got the timezone
setting reseted by a package upgrade, maybe it was Slackware 9.1 or
somewhere around that era.
Looking at the doinst.sh for the glibc-zoneinfo-2011i_2011n-noarch-1.tg
for Slackware 9.1 it does seem to use symlinks, but seem to mess with
etc/localtime unless etc/localtime-copied-from already exist and that
file (or link) does not seem to be created by the original
glibc-zoneinfo-2.3.2-noarch-1.tgz for Slackware 9.1.

Ah, you /might/ have found the culprit there. A bug in the initial
installed package that failed to install the sentinel file indicating
which zone the /etc/ file was copied from.

[Rich]

Post by Henrik Carlqvist

Post by Rich
If you go back in time far enough, yes, the Slackware installer did a
"cp /usr/share/zoneinfo/xx/yyy /etc/localtime" to set your timezone.
I don't recall what version made the switch to the symlink.

I don't remember for sure which version of Slackware got the timezone
setting reseted by a package upgrade, maybe it was Slackware 9.1 or
somewhere around that era.
Looking at the doinst.sh for the glibc-zoneinfo-2011i_2011n-noarch-1.tg
for Slackware 9.1 it does seem to use symlinks, but seem to mess with
etc/localtime unless etc/localtime-copied-from already exist and that
file (or link) does not seem to be created by the original
glibc-zoneinfo-2.3.2-noarch-1.tgz for Slackware 9.1.

FWIW, Slack 13.1 still has the copied file and the sentinel 'copied
from' symlink.

So the switch to a pure symlink for /etc/localtime happened sometime
after 13.1. 15.0 has just the symlink for /etc/localtime.