Solved Questions about orphaned packages

V

VulcanRidr

I am running 14.2p3 on my laptop and desktop, and I get some strange results:


Code: 
sudo pkg version -vRL=
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Nessus-10.6.2                      ?   orphaned: security/Nessus
chromium-135.0.7049.95             ?   orphaned: www/chromium
clusterssh-4.16                    ?   orphaned: security/clusterssh
gcc10-10.5.0_1                     ?   orphaned: lang/gcc10
gcc9-9.5.0_2                       ?   orphaned: lang/gcc9
libfame-0.9.1_7                    ?   orphaned: multimedia/libfame
openjdk13-13.0.11+4.1              ?   orphaned: java/openjdk13
py39-SecretStorage-3.3.1           ?   orphaned: security/py-SecretStorage
py39-cffi-1.16.0                   ?   orphaned: devel/py-cffi
py39-click-8.1.7                   ?   orphaned: devel/py-click
py39-cryptography-42.0.7,1         ?   orphaned: security/py-cryptography
py39-dbus-1.3.2                    ?   orphaned: devel/py-dbus
py39-fido2-1.1.3                   ?   orphaned: security/py-fido2
py39-importlib-metadata-7.1.0      ?   orphaned: devel/py-importlib-metadata
py39-jaraco.classes-3.4.0          ?   orphaned: devel/py-jaraco.classes
py39-jeepney-0.8.0_2               ?   orphaned: devel/py-jeepney
py39-keyring-23.9.3_2,1            ?   orphaned: security/py-keyring
py39-more-itertools-10.2.0         ?   orphaned: devel/py-more-itertools
py39-openssl-23.2.0,1              ?   orphaned: security/py-openssl
py39-pycparser-2.22                ?   orphaned: devel/py-pycparser
py39-pyscard-2.0.3                 ?   orphaned: security/py-pyscard
py39-pyusb-1.2.1                   ?   orphaned: devel/py-pyusb
py39-six-1.16.0                    ?   orphaned: devel/py-six
py39-yubikey-manager-5.2.0         ?   orphaned: security/py-yubikey-manager
py39-zipp-3.19.0                   ?   orphaned: devel/py-zipp

I have the following questions:

  1. Why are things like Nessus, chromium, and clusterssh showing up as orphaned? These are packages I have installed.
  2. I have gcc9 through gcc13 installed. Do I really need all of these version of the compiler? Same applies to openjdk. I have 8, 13, and 17 installed.
  3. Finally, the system runs python311. Can I remove the python39 and all of the py39 packages? Do I need to install the ones that exist under python 3.11? Two are already installed, and another 6 show up in pkg search. The reason I ask is that on linux, you generally do not go in and do wholesale overhauls on python, since that tends to break the system.
Thanks,
--vr
 
VulcanRidr said:
I have gcc9 through gcc13 installed. Do I really need all of these version of the compiler? Same applies to openjdk. I have 8, 13, and 17 installed.
Click to expand...
Nope, lang/gcc13 is sufficient. I normally have that installed/compiled very early on.

Unfortunately, you do need all those JDK versions - the earlier ones bootstrap the later ones, it's just the way that Java is compiled. It's not nearly as bad as it used to be in the past - I still have nightmares about the nearly infinite dependency recursions when it went from jdk6 to 7 to 8, and kept going until jdk 15! I mean, seriously, I wanted to compile only JDK 16, it was depending on 15, which in turn, depended on 14, and that kept going on for what seemed like infinity!

VulcanRidr said:
Finally, the system runs python311. Can I remove the python39 and all of the py39 packages? Do I need to install the ones that exist under python 3.11? Two are already installed, and another 6 show up in pkg search. The reason I ask is that on linux, you generally do not go in and do wholesale overhauls on python, since that tends to break the system.
Click to expand...
I would leave the Python stuff alone. Removing the py39 packages and replacing them with py311 ones is probably more than pkg-upgrade(8) can handle. I expect that move to break the system on FreeBSD, as well. I do think that a clean reinstall of the entire system is the only practical way to move from py39 to py311.
 
astyle said:
the earlier ones bootstrap the later ones, it's just the way that Java is compiled.
Click to expand...
They can use the previous version to build the new version, but they're also perfectly fine bootstrapping themselves. Packages don't need to be built, so you don't need to leave a bunch of build dependencies around either. If you have nothing depending on the old JDK versions just remove them.
 
astyle said:
Removing the py39 packages and replacing them with py311 ones is probably more than pkg-upgrade(8) can handle.
Click to expand...
Not my experience, it generally works, but you need to watch out for the old python version flavored packages, it's going to keep those and not replace them with their 3.11 flavored counterpart, you need to instruct pkg(8) to do that. How to do this is explained in UPDATING.

POSIX.1 said:
Upgrading Python major releases is not that difficult.
Click to expand...
Agreed. It's really not that difficult, you just have to be a bit more diligent when doing package upgrades .
 
POSIX.1 said:
Sorry, but this is bad overblown advice. Upgrading Python major releases is not that difficult.
Click to expand...
Yes, it seems the systems did it all by themselves for the most part. I was just wondering because most of the py39 packages are listed as orphaned, which implied to me "not receiving any updates/security patches"...Which is what raised the question in the first place.
 
VulcanRidr said:
True, however I was using the pkg from tenable.
Click to expand...
You asked why the package showed up as 'orphaned', it doesn't exist in the FreeBSD repositories.
Code: 
     ?       The installed package does not appear in the index.  This could
             be due to an out of date index or a package taken from a PR that
             has not yet been committed.
pkg-version(8)

VulcanRidr said:
I was just wondering because most of the py39 packages are listed as orphaned, which implied to me "not receiving any updates/security patches"...Which is what raised the question in the first place.
Click to expand...
The default changed some time ago, and there's nothing depending on the Python 3.9 modules, so they're not getting built, thus no packages for them. I'm fairly certain a pkg-autoremove(8) will remove them.
 
The problem with upgrading just the Python packages is that they tend to be dependencies of all kinds of non-python stuff. For example, if www/qt6-webengine was compiled to depend on py39-whatever stuff, upgrading just that py39-whatever (to its py311 counterpart) is NOT going to resolve to upgrading the www/qt6-webengine port. That will result in a broken www/qt6-webengine.

I've had that stuff bite me enough times to learn that a clean reinstall is a safer way to upgrade.

Just try figuring out the dependency graph. People have complained about how pkg wants to remove Firefox whenever they run pkg-upgrade. Removing Firefox is not something that most rank-and-file users can stomach. Yeah, there's workarounds that gum up the dependency resolution algorithm, but they only postpone the inevitable clean reinstall that has to happen after everything breaks.

It's just as bad (and can be even worse) in Linux camp.
 
bakul said:
This is described in /usr/ports/UPGRADING file. Look for the 20240529 entry.
Click to expand...
Ummm... I think it's /usr/ports/UPDATING, rather than /usr/ports/UPDGRADING.

Other than that, yeah, it does describe an approach that can be used - if the user can follow the instructions precisely and not skip steps.
 
Yes it's "UPDATING" and one can just cut and paste 3 lines.
sh
for i in $(pkg query -g %n 'py39-*'); do pkg set -yn ${i}:py311-${i#py39-}; done
pkg upgrade

It works just fine.
 
mer said:
sh
for i in $(pkg query -g %n 'py39-*'); do pkg set -yn ${i}:py311-${i#py39-}; done
pkg upgrade
Click to expand...
First: consider using a code block, because the above doesn't only work.. it also tries to mock us! :what:

Also... it wouldn't even work anyway because: why sh? You're missing a shebang: #!/bin/sh. <= My oversight (= edit2), this is indeed the safer way to go about your command.

(edit) => Also also: your command has the potential to b0rk OP's box even more. Trying to force stuff on an instable system is not a good idea.
 
I don't disagree with you but I was operating under the assumption that anyone executing these commands would have the text for UPDATING available.
code block would have been clearer but I was trying to point out the lines, not make them cut/pastable from here.

As for borking the OP box even more, I disagree. I had a system with about the same 32 python packages showing the same orphaned status, I simply ran the commands from UPDATING with no issues.
So could it have made things worse? Sure. But any command on a partially broken system can make it worse, make it better or make no difference.
Roll the dice, hedge your bets.
 
astyle said:
Ummm... I think it's /usr/ports/UPDATING, rather than /usr/ports/UPDGRADING.

Other than that, yeah, it does describe an approach that can be used - if the user can follow the instructions precisely and not skip steps.
Click to expand...
Indeed. A senior moment :-)
 
mer said:
I don't disagree with you but I was operating under the assumption that anyone executing these commands would have the text for UPDATING available.
code block would have been clearer but I was trying to point out the lines, not make them cut/pastable from here.

As for borking the OP box even more, I disagree. I had a system with about the same 32 python packages showing the same orphaned status, I simply ran the commands from UPDATING with no issues.
So could it have made things worse? Sure. But any command on a partially broken system can make it worse, make it better or make no difference.
Roll the dice, hedge your bets.
Click to expand...
Do you think that rank-and-file users would have enough diligence to actually read /usr/ports/UPDATING BEFORE running pkg-upgrade(8)?

I don't think so... FWIW, I myself have never read that file until today, and it never even registered with me what kind of content it's got.

Running commands blindly will bork OP's box even more. Sometimes, you gotta ask, what's easier for OP - sifting through a train wreck and lifting the existing train back up onto the track or to clean up and launch a brand-new train? I'd say that most of the time, ROI analysis would point to launching a brand-new train.
 
SirDice said:
You asked why the package showed up as 'orphaned', it doesn't exist in the FreeBSD repositories.
Code: 
     ?       The installed package does not appear in the index.  This could
             be due to an out of date index or a package taken from a PR that
             has not yet been committed.
pkg-version(8)


The default changed some time ago, and there's nothing depending on the Python 3.9 modules, so they're not getting built, thus no packages for them. I'm fairly certain a pkg-autoremove(8) will remove them.
Click to expand...
Okay, that makes perfect sense. And I just looked and tenable has since dropped the FreeBSD version of nessus, so I guess that is a dead horse I'm beating. :)
 
astyle said:
Do you think that rank-and-file users would have enough diligence to actually read /usr/ports/UPDATING BEFORE running pkg-upgrade(8)?

I don't think so... FWIW, I myself have never read that file until today, and it never even registered with me what kind of content it's got.

Running commands blindly will bork OP's box even more. Sometimes, you gotta ask, what's easier for OP - sifting through a train wreck and lifting the existing train back up onto the track or to clean up and launch a brand-new train? I'd say that most of the time, ROI analysis would point to launching a brand-new train.
Click to expand...
Yeah, you may remember me from the attempts to upgrade to kde6. :D That is when i learned about the UPDATING file... That said, I do my pkg upgrades via ansible, and I also got into the habit of, prior to pkg upgrade-ing, deleting and re-creating a fresh Before_pkgUpgrade boot environment, so I can roll back from...um...unintended consequences.
 
SirDice said:
You asked why the package showed up as 'orphaned', it doesn't exist in the FreeBSD repositories.
Code: 
     ?       The installed package does not appear in the index.  This could
             be due to an out of date index or a package taken from a PR that
             has not yet been committed.
pkg-version(8)


The default changed some time ago, and there's nothing depending on the Python 3.9 modules, so they're not getting built, thus no packages for them. I'm fairly certain a pkg-autoremove(8) will remove them.
Click to expand...
Ironically enough, pkg autoremove does not, in fact, try to remove them.

Code: 
sudo pkg autoremove
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 9 packages:

Installed packages to be REMOVED:
        accounts-qml-module: 0.7_5
        java-zoneinfo: 2021.e
        libfame: 0.9.1_7
        libgweather: 40.0_6
        libwpe: 1.12.0
        ncurses: 6.5
        py311-setuptools: 63.1.0_3
        spirv-llvm-translator-llvm15: 15.0.11
        wpebackend-fdo: 1.12.0
 
VulcanRidr said:
Ironically enough, pkg autoremove does not, in fact, try to remove them.
Click to expand...
Then you have something still depending on them, or they've not been automatically installed. Autoremove only removes packages if there's nothing depending on them and they've been 'automatically' installed.
 
SirDice said:
Then you have something still depending on them, or they've not been automatically installed. Autoremove only removes packages if there's nothing depending on them and they've been 'automatically' installed.
Click to expand...
Apparently I don't because if I tell it to remove python39, only the py39 packages, and no downstream packages are marked for destruction:

Code: 
Installed packages to be REMOVED:
        py39-SecretStorage: 3.3.1
        py39-cffi: 1.16.0
        py39-click: 8.1.7
        py39-cryptography: 42.0.7,1
        py39-dbus: 1.3.2
        py39-fido2: 1.1.3
        py39-importlib-metadata: 7.1.0
        py39-jaraco.classes: 3.4.0
        py39-jeepney: 0.8.0_2
        py39-keyring: 23.9.3_2,1
        py39-more-itertools: 10.2.0
        py39-openssl: 23.2.0,1
        py39-pycparser: 2.22
        py39-pyscard: 2.0.3
        py39-pyusb: 1.2.1
        py39-setuptools: 63.1.0_3
        py39-six: 1.16.0
        py39-yubikey-manager: 5.2.0
        py39-zipp: 3.19.0
        python39: 3.9.22

Number of packages to be removed: 20

...Unless I am missing something...
 
VulcanRidr said:
Apparently I don't because if I tell it to remove python39, only the py39 packages, and no downstream packages are marked for destruction:

Code: 
Installed packages to be REMOVED:
        py39-SecretStorage: 3.3.1
        py39-cffi: 1.16.0
        py39-click: 8.1.7
        py39-cryptography: 42.0.7,1
        py39-dbus: 1.3.2
        py39-fido2: 1.1.3
        py39-importlib-metadata: 7.1.0
        py39-jaraco.classes: 3.4.0
        py39-jeepney: 0.8.0_2
        py39-keyring: 23.9.3_2,1
        py39-more-itertools: 10.2.0
        py39-openssl: 23.2.0,1
        py39-pycparser: 2.22
        py39-pyscard: 2.0.3
        py39-pyusb: 1.2.1
        py39-setuptools: 63.1.0_3
        py39-six: 1.16.0
        py39-yubikey-manager: 5.2.0
        py39-zipp: 3.19.0
        python39: 3.9.22

Number of packages to be removed: 20

...Unless I am missing something...
Click to expand...
Well, this tells me that python39 is reasonably safe to remove. Well, I'm not a fan of getting into this much detail of dependency management. I want to spend my time using the machine, rather than managing the bejeezus out of a system whose complexity has the propensity to bite if not managed right.
 
VulcanRidr said:
Apparently I don't because if I tell it to remove python39, only the py39 packages, and no downstream packages are marked for destruction
Click to expand...
Looks that way. If you want to check which of them may have been 'non-automatic', a bit of pkg-query(8) magic will tell you: pkg query -x '%o: %a' py39

Code: 
     %o  Origin of the matched package
{..}
     %a  Returns 1 if the matched package was automatically installed as a
         dependency of another package, 0 otherwise.  The package can be
         automatically removed via ‘pkg autoremove’ when this flag is set and
         no other package depends on it.
 
You must log in or register to reply here.
Back
Top