Dangerously broken dependencies in package "APT"

[Tokarak]

I upgraded apt to 2.5.2 today using Sileo (to whom I will transfer the issue to if it turns out the problem isn't here). Apt gives the following error now:

An unknown error occurred. APT was unable to find this package. Please try refreshing your sources dyld: Symbol not found: _ie_getgrnam Referenced from: /usr/lib/libapt- pkg.6.0.dylib Expected in: /usr/lib/libiosexec.1.dylib

I poked around on my device, and found that the libiosexec is on an older version. (1.0.20) while the latest is 1.2.2. I am assuming the older version does not have that symbol.

The error, I am guessing, is in the dependencies of apt. The minimum libiosexec version needs to be bumped. To what? I am not sure, as Sileo does not show and apt is, haha, broken. Someone else needs to work out in which version that symbol was introduced.

Isn't there a GitHub CI which tests with the minimum versions specified? I think that should prevent similar events in the future. I am unfamiliar with CI, so I couldn't say how practical that would be.

Thankfully, dpkg seems to work. I will manually upgrade libiosexec using dpkg to work myself out of this pothole.

[CRKatri]

A dpkg update was published a few weeks ago with a dependency on libiosexec >= 1.2.1, we believed that most people would have the new version installed by now, or at least update all of their packages at the same time so that this would not be an issue. I am wondering why you updated apt but not dpkg?

[Tokarak]

Bad luck, I suppose. "Upgrade all", gave an error, so I started batch upgrading. First batch I picked turned out to break my system.

[Tokarak]

libiosexec should be a dependency, because dpkg can and does work on an older version. Apt has a direct dep on libiosexec > 1.2.1.

[0xallie]

A dpkg update was published a few weeks ago with a dependency on libiosexec >= 1.2.1, we believed that most people would have the new version installed by now, or at least update all of their packages at the same time so that this would not be an issue. I am wondering why you updated apt but not dpkg?

Can we not make Procursus the next Arch, please? Is it that hard to explicitly declare all your dependency versions to prevent any chance of breakage rather than blaming the user? They didn't do anything crazy like messing with apt/dpkg on the CLI, they simply tried to update their packages. If another package must be also updated if you update one package then specify so in the control file. Generally most people will want to be on the latest version of every package but there may be valid reasons to keep certain packages downgraded. (And in this case they didn't even want to keep them downgraded, they only tried updating one by one because upgrading all packages failed.)

[asdfugil]

A dpkg update was published a few weeks ago with a dependency on libiosexec >= 1.2.1, we believed that most people would have the new version installed by now, or at least update all of their packages at the same time so that this would not be an issue. I am wondering why you updated apt but not dpkg?

Can we not make Procursus the next Arch, please? Is it that hard to explicitly declare all your dependency versions to prevent any chance of breakage rather than blaming the user? They didn't do anything crazy like messing with apt/dpkg on the CLI, they simply tried to update their packages. If another package must be also updated if you update one package then specify so in the control file. Generally most people will want to be on the latest version of every package but there may be valid reasons to keep certain packages downgraded. (And in this case they didn't even want to keep them downgraded, they only tried updating one by one because upgrading all packages failed.)

sounds like something to do in PACK (Add that depend if there are any Mach-Os in the package)

[asdfugil]

especially since macOS does not have libiosexec so some logic is required anyways unless you want a .control.macosx for every package.

[Kyogre]

Hello everyone! Got that problem on my ipad too by updating only apt via Zebra 1.1.28.

Solved it this way:

1. I have copied libraries from my iphone 12 mini which already have all packages updated to my ipad. You can grab it from this archive: symbol not found _ie_getgrnam libiosexec fix.zip. It contains two libz-ng.2.dylib libs (needed for dpkg to install .deb of the new libiosexec) and the .deb itself.
2. Placed all dylibs from archive to /usr/lib (with overwrite), and placed libiosexec1_1.2.2_iphoneos-arm.deb to /var/mobile/Documents.
3. Assigned correct permissions for all three dylibs via Filza. You can check what permissions are correct from properties of dylibs that are already in /usr/lib. Mine permissions were:

root
wheel

read, write
read
read

4. Updated dpkg package via Zebra or Installer5 (I don't remember which one package manager I used, and maybe dpkg doesn't need to be updated at all...).
5. Via NewTerm executed command sudo dpkg -i /var/mobile/Documents/libiosexec1_1.2.2_iphoneos-arm.deb (maybe I could install this .deb via Zebra or Filza, but I have chosen to install it via terminal).
6. Via Zebra installed latest libz-ng2 dependency.
7. Reinstalled dpkg package via Zebra. Now everything works fine, packages will install without a problems.

I will manually upgrade libiosexec using dpkg to work myself out of this pothole.

@Tokarak can you tell how have you done this with only dpkg? As I said, I were caught in a loop with missing libiosexec.1.dylib v1.2.2 until I copied it manually from my iphone to my ipad.

[Tokarak]

@Kyogre When I upgraded only apt, I did not upgrade dpkg; I did not touch libiosexec either. apt was broken because it depended on a newer version of libiosexec; dpkg was still functioning. So I manually cURL-ed the new libiosexec from source and install it with dpkg. You must have also upgraded dpkg, if it was not functioning.