Debian package securedrop-app-code is not getting upgraded

[kushaldas]

Bug

Description

In my prod vm securedrop-app-code package is not getting upgraded.

Steps to Reproduce

Follow the QA steps to fetch the latest packages from apt-test repo.

Expected Behavior

We should get the 0.7~RC1 packages.

Actual Behavior

$ dpkg -al | grep secure
ii  openssh-client                       1:6.6p1-2ubuntu2.10                        amd64        secure shell (SSH) client, for secure access to remote machines
ii  openssh-server                       1:6.6p1-2ubuntu2.10                        amd64        secure shell (SSH) server, for secure access from remote machines
ii  openssh-sftp-server                  1:6.6p1-2ubuntu2.10                        amd64        secure shell (SSH) sftp server module, for SFTP access from remote machines
ii  secure-delete                        3.1-6                                      amd64        tools to wipe files, free disk space, swap and memory
ii  securedrop-app-code                  0.6                                        amd64        Packages the SecureDrop application code pip dependencies and apparmor profiles. This package will put the apparmor profiles in enforce mode. This package does use pip to install the pip wheelhouse
ii  securedrop-config                    0.1.1+0.7.0~rc1                            all          Establishes baseline system state for running SecureDrop.
ii  securedrop-grsec                     4.4.115+r1                                 amd64        Metapackage providing a grsecurity-patched Linux kernel for use
ii  securedrop-keyring                   0.1.1+0.7.0~rc1                            amd64        Provides an apt keyring for SecureDrop-related packages, so the master signing key used for SecureDrop packages can be updated via apt.
ii  securedrop-ossec-agent               2.8.2+0.7.0~rc1                            amd64        Installs the securedrop pre-configured OSSEC agent
ii  ssh-import-id                        3.21-0ubuntu1                              all          securely retrieve an SSH public key and install it locally

$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  securedrop-app-code
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

[kushaldas]

It seems if I manually do a sudo apt-get update and then sudo apt upgrade, it pulls in the right dependencies and the upgraded package.

[redshiftzero]

Did you figure out why your manual intervention was necessary @kushaldas?

[kushaldas]

In my latest testing I could not reproduce this error. I am closing this issue.

[redshiftzero]

Reopening because I also see this same behavior while upgrade testing 0.7.0~rc3 on hardware - the securedrop-app-code package was held back at 0.6. All other packages upgraded without intervention. But if so it's unclear why you didn't see this in further testing @kushaldas. Hypothesis: this is due to the addition of the libjpeg-dev dependency in 9880a30

[redshiftzero]

It looks like @emkll and @dachary also performed upgrade testing - did you experience this issue?

[kushaldas]

@redshiftzero yes, it is missing libjpeg-dev package dependency and that is why it is holding back. In my last testing sudo cron-apt -s -i actually did a apt-get update, so it found the proper dependencies and upgraded to the right securedrop-app-code package.

[redshiftzero]

Do you understand why this only happens in some situations? cron-apt -s -i always does an apt-get update first, no?

[kushaldas]

Do you understand why this only happens in some situations? cron-apt -s -i always does an apt-get update first, no?

Yes (about doing that apt-get update by cron-apt -s -i), but, for some reason it failed for me once, I am guessing the same happened to you too.

did you experience this issue?

I did not. Could it be that something installs libjpeg-dev when running vagrant up app-prod?

[msheiny]

yeah im able to also reproduce this on my instance... digging

[msheiny]

Sooo I think this might be by design on debian's side ... I'm having trouble finding links explaining this behavior but as an analogy it seems to be similar to how permissions work on Android apps:

• You have an app Foo that you previously installed
• New updates to Foo come in without new permission changes and can be automatically updated
• Say one day Foo updates but is now requiring access to your Camera ... Android wants you to manually approve that change in underlying app dependency.

This article had a really good quote summing this up:

If I may try to rephrase: 'Apt-get dist-upgrade'ing also installs new packages brought in the chain of dependencies, whereas 'apt-get upgrade'ing only install newer versions of packages already installed. After a couple of years working with Debian, I never managed to exactly understand that difference. Would you believe I never found documentation who states this as simple?

Still diggin into solutions here