Ubuntu PPA installs PHP 8.0RC1 automatically???

  • This topic has 16 replies, 1 voice, and was last updated 2 months ago by hashtagframework.
Viewing 15 posts - 1 through 15 (of 17 total)
  • Author
  • #2074

    This morning several of the production / staging systems we use that run PHP7 and on an unattended upgrades all of a sudden installed PHP8.0 RC1 from the ondrej PPA. Anyone else have this happen? Not only is ondrej supposed to be a 5.x / 7.x release channel but promoting out a release candidate as part of the primary PPA and not a Dev/Staging? I mean I know there’s some onus on our team to ensure we’re version pinned and generally our tools do ensure we’re running the correct version but the unattended upgrade shouldn’t install an RC…

    Edit 2: *What really happened*

    It may have been our UAGs or it may have been chef ensuring our packages were up to date for the php7.2* set we wanted installed. We are version pinning in that sense. What happened as far as we can tell is, on the machines that were affected, SOME had, at one point, had one of the php-extension meta packages installed before being switched to the explicit php7.2-extension version. What didn’t happen was a purge of the meta before installing the version locked one. It appears that during an “upgrade” Ubuntu decided that it should update the meta version which caused, according to [https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706754897](https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706754897), ALL versions of PHP to be installed. In a comedy of errors. Ubuntu, at the PPA’s bequest, set the auto alternative to php8.0 which broke everything.

    IMO this is some serious bullshit that even using explicit package installations that a meta package can install complete sets of software without asking and FURTHER set the default to versions never asked for nor even ready for a production environment. It should be a system where we get what we ask for and nothing else. Not only do we now have to ensure that we never use a meta package, we have to add black lists like below, AND we have to ensure the alternatives are managed through whatever tool in use.

    This wouldn’t have been as much of a problem if the systems didn’t decide to UPDATE THE ALTERNATIVE automatically!! WTH??


    Edit: For now we’re adding the following lines to our servers to help keep this from happening:

    Package: php8.0*
    Pin: release *
    Pin-Priority: -1

    Package: php5.6*
    Pin: release *
    Pin-Priority: -1

    Package: php7.3*
    Pin: release *
    Pin-Priority: 100

    Package: php7.*
    Pin: release *
    Pin-Priority: -1

    This ensures we don’t install versions we don’t want


    Unattended updates on Sunday?


    that is scary, thanks for mentioning this. will watch our builds closely this upcoming week


    What’s the exact command you’re using to install PHP please?

    Asking as it might be a problem that needs to be fixed by the PPA urgently, or it might be something you’re doing that inadvertently asks for the latest version no matter stability.


    Did your application still work though?


    The same for me on Ubuntu 18.04 LTS, running php7.2. The only thing changed it was the CLI version for PHP – it went to php8, but the fix was quite simple on this case: `update-alternatives –set php /usr/bin/php7.2`


    seems like the main issue has been resolved, see [https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706889681](https://github.com/oerdnj/deb.sury.org/issues/1465#issuecomment-706889681)

    > I think I found a way how to circumvent the problem other way. The individual packages don’t depend on matching phpapi-<ver> now, so they don’t pull any of the SAPIs. That way when you do apt install php7.4-apcu it won’t pull php7.4-cli which leaves your system just with the binary extension and nothing to use it with, but that way installing php-apcu will just install the PHP extensions and not all the PHP releases available.

    I justed tested this on a dev system and a `apt update` + `apt upgrade` only installs 8.0 extensions (for the meta packages like memcached etc.) but no php8.0-cli package


    Thanks, had the same issue! Updating the alternative back to the version it should work was working as a quick way to restore things, and we’re adding your prefs.d as we speak now 🙂




    Same here… It also installed swaths of 5.6, 7.2 and 7.3. Took me a while to cleanup, thankfully nothing tried to use 8.0.


    Yea…. this is why I don’t do unattended updates.


    ngl this shit fucked with me today. Thank you for posting about it. Still trying to sort it out.


    Haha, I had the same yesterday.

    Installed all other modules with this command:

    sudo apt-get install -y php8.0 php8.0-imagick php8.0-bcmath php8.0-pgsql php8.0-sqlite php8.0-dom php8.0-apcu php8.0-mbstring php8.0-intl php8.0-gd php8.0-mysql php8.0-zip php8.0-fpm php8.0-curl



    We have unattended installs activated too and actively using ondrejs Deb repo. No automatic upgrading of PHP though … seems like your unattended-upgrades isnt setup properly, no?

Viewing 15 posts - 1 through 15 (of 17 total)
  • You must be logged in to reply to this topic.