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

[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.