search

deadsnakes / issues

Issues for https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa
86 stars 6 forks source link

Broken upgrades #158

Closed nafallo closed 3 years ago

nafallo commented 3 years ago

python3.8 installed on Ubuntu 18.04 and then doing do-release-upgrade leaves a broken system since your python3.8 is a later version than the one included in Ubuntu 20.04.

I reckon you might need to install a hook to uninstall your python3.8 packages so that the correct versions gets installed.

asottile commented 3 years ago

as far as I know there's no such hook but I'm willing to be wrong

whenever I upgrade systems I uninstall all ppas before doing so

nafallo commented 3 years ago

I know there isn't one. I suggested there should be one.

Or at least that it would be one possible solution to the problem that my end-user now has a system that can't install security upgrades on Ubuntu 20.04 because of broken dependencies.

asottile commented 3 years ago

maybe propose that to debian then? I am but a simple ppa with little to no say about how dpkg works

nafallo commented 3 years ago

Sorry what? Can you explain what you meant with that comment in relation to this issue please?

nafallo commented 3 years ago

Your python3.8 from Ubuntu 18.04 is a later dpkg version than what's in Ubuntu 20.04. When you upgrade the your Ubuntu version your packages are left in place, and blocks security upgrades...

E:Unable to correct problems, you have held broken packages. The following packages have unmet dependencies: gdb: Depends: libpython3.8 (>= 3.8.2) but is not installable libpeas-1.0-0: Depends: libpython3.8 (>= 3.8.2) but is not installable libpython3-dev: Depends: libpython3.8-dev (>= 3.8.2-1~) but is not installable samba-libs: Depends: libpython3.8 (>= 3.8.2) but is not installable samba-libs: Depends: python3-talloc (>= 2.2.0~) but is not installable

asottile commented 3 years ago

right, unless you know of such a hook -- I don't think there's anything I can do to fix that without changing how do-release-upgrade or dpkg works

asottile commented 3 years ago

you can fix it after the fact by force-downgrading packages fwiw -- but I don't think there's anything actionable from the packaging side

nafallo commented 3 years ago

My suggestion was that you look into providing a hook to do-release-upgrade so that it falls back to the distro packages :-). The package already supports those hooks, you just need to provide one if you would agree with that solution.

Another solution would be to only backport versions from the next LTS for the previous one (backport) and adjust your dpkg version so that the next LTS packages are higher. You can test with for example:

  if $(dpkg --compare-versions "3.8.8-1+bionic2" "lt" "3.8.5-1~20.04"); then echo true; fi
  if $(dpkg --compare-versions "3.8.5-1~0bionic2" "lt" "3.8.5-1~20.04"); then echo true; fi

Well, I'm actually seeing this problem on one of my end user's workstation. It's not /my/ machine, so I have to push stuff manually to this machine now to fix it ;-).

The downgrades I've been trying to force so far haven't worked, hence I want to resolve this situation before it occurs in future :-).

nafallo commented 3 years ago

But yeah, this is an issue, and I think this should be reopened :-)

asottile commented 3 years ago

The package already supports those hooks, you just need to provide one if you would agree with that solution

Show me

nafallo commented 3 years ago

Hmm. PostInstallScripts are possible. Not sure the codebase supports to define quirks out of source code right now.

To run a postinstall script to downgrade the packages you would define a file ending in .cfg within /etc/update-manager/release-upgrades.d/ with:

[Distro]
PostInstallScripts=./xorg_fix_proprietary.py, <path to your script>
nafallo commented 3 years ago

I've downgraded this for the affected computer now, but it would be less helpful by me to just fix this locally rather than providing information about what breaks. Personally I would probably start by thinking about the dpkg version comparisons, since that is clearly the better fix here.

$ if $(dpkg --compare-versions "3.8~3.8.8-1+bionic2" "lt" "3.8.5-1~20.04"); then echo true; fi
true

Perhaps something like the above could work in the future? The problem now is that the 18.04 version from your PPA already override the 20.04 version from the archive, so it's not likely to be easily fixable there.

asottile commented 3 years ago

I don't think a postinstall hook wouldn't help, the package is already installed so the hook would not get triggered

changing the version isn't really an option -- that would break currently installed packages and it would diverge further from upstream and it would break gbp

But yeah, this is an issue, and I think this should be reopened :-)

please don't tell me how to run my project, thanks