install command doesn't install updates

[ghost]

Using the current source in github, I can run apt-offline set apt-offline.sig --upgrade without issue, and apt-offline get apt-offline.sig --bundle upgrade.zip creates a zipfile that does indeed have the debs of the packages that need to be upgraded. However, running apt-offline install upgrade.zip --verbose doesn't seem to install the packages onto my system. The command output says that the packages are "synced", and I don't see any errors.

[ghost]

Debugging AptOfflineCoreLib.installer, I see that none of the debs make it into verifiedList (line 2081). If it's the case that there are problems with the package signatures, I would expect an error or warning message to be printed.

[rickysarraf]

Not necessarily. apt-offline strictly delegates the package verification to apt. apt-offline does a md5/sha checksum validation depending on what is mentioned in the signature file. If correct, it keeps the payload. On install, it simply delegates further validation to apt.

Please share full verbose console output of apt-offline install upgrade.zip --verbose here.

[ghost]

I'll include that in another message, but I've been stepping through the code, and I don't understand how it's supposed to work. AptOfflineCorLib.installer will only install things from verifiedList, but I don't see how debs could possibly make it into this list from InstallerInstance.verifyAptFileIntegrity since it only inspects files ending with .gpg and InRelease.

I'm still trying to wrap my head around the codebase (it's quite complex), and I don't know a ton about how apt works under the hood, but I'm not seeing the place where packages get installed. They're being successfully copied to /var/cache/apt/archives, but they just sit there.

[ghost]

As promised, here is apt-offline-install.log. To illustrate the bundle created by apt-offline get,
here is a listing of the zip file contents.

[rickysarraf]

I'll include that in another message, but I've been stepping through the code, and I don't understand how it's supposed to work. AptOfflineCorLib.installer will only install things from verifiedList, but I don't see how debs could possibly make it into this list from InstallerInstance.verifyAptFileIntegrity since it only inspects files ending with .gpg and InRelease.

That's only for the apt metadata, which holds the actual checksum integrity for everything else.

I'm still trying to wrap my head around the codebase (it's quite complex), and I don't know a ton about how apt works under the hood, but I'm not seeing the place where packages get installed. They're being successfully copied to /var/cache/apt/archives, but they just sit there.

They should never be installed to /var/cache/apt/archives/
See this:

apt-offline/apt_offline_core/AptOfflineCoreLib.py

Line 2074 in 7cfa5fc

if os.access( InstallerInstance.apt_package_path, os.W_OK ):

Now, why/how did the .debs get copied there instead, is something to investigate. You mentioned that you are using the latest code from the git repository. So you should have the latest.

[rickysarraf]

I think I see the problem. But, in summary, I don't know why it is behaving that way. It probably is an Ubuntu specific behavior. If you instead use the --strict-deb-check option, then it'll do a stricter validation of the .debs. And probably that'll make things better.

I don't use Ubuntu so this is just a guess. But I haven't seen this behavior on my Debian systems. If you are interested in how the whole validation thing works, I wrote a small blog post some time ago. That may help clarfiy some of your doubts.

https://www.researchut.com/blog/apt-offline-1_8_2/

To just emphasize a snippet from the manpage:

       --strict-deb-check
                 With this option enabled, apt-offline delegate's .deb package checksum validation to apt. While the .debs are already available, they are stored in the temporary apt cache,
                 where  apt  validates  its  checksum,  before  considering it for further processing.  Note: This does have the caveat that apt may need network availability even though it
                 doesn't download anything over the network. But it does invoke the download routines and realizes that the payload is already  available.  It  then  further  proceeds  with
                 checksum validation

                 The default behavior is to not do strict checksum validation for .deb files. Instead, apt-offline copies the .deb files to apt's download location. apt still does size val‐
                 idation of the available .deb files and discards them in case there is a mismatch.

[rickysarraf]

They should never be installed to /var/cache/apt/archives/ See this:

So this statement from me is wrong. from the manpage, it is clear that the default behavior is to not do strict deb checking. Which is what is reflected in your runs too.

But I think this overall anomaly is just because Ubuntu is doing a stricter validation of the .debs, which is a good thing. I think if you use the --strict-deb-check option, it should work proper. The only caveat is a cosmetic message in the workflow

[ghost]

Unfortunately I can confirm that --strict-deb-check does not result in the package being installed.

I would love to help debug this issue, as I am pretty comfortable with Python. Can you point me to the line where "installation" actually happens? I feel like my lack of familiarity with apt is a barrier here.

[rickysarraf]

Unfortunately I can confirm that --strict-deb-check does not result in the package being installed.

I would love to help debug this issue, as I am pretty comfortable with Python. Can you point me to the line where "installation" actually happens? I feel like my lack of familiarity with apt is a barrier here.

apt-offline strictly delegates the actual installation task to apt. It doesn't perform any installation by itself. The blog article should give you details on the workflow.

There's nothing much for apt-offline here. This behavior, that of not honoring the downloaded debs, is particular to the distribution in use. So what has changed is something to investigate on the host machine.

So what host machine distribution are you running ? It was my bad to assume that you were on Ubuntu.

[rickysarraf]

See the example runs in this report which I ran today.
#165

[sean-anderson-seco]

I am running Ubuntu and I see this issue.