Regarding that openssl, I believe you're correct about something requiring it, however if that's the case it must be something in php 7.3, because nothing in 7.2 needed to pull it in. However the regular update/upgrade process of course wants to pull it in as long as the repo is active.

This actually gave me an idea and I tried totally redoing the upgrade with the following steps:

1. Upgrade wth "apt update" and "apt dist-upgrade".

2. Added the new repo.

3. Removed all php5 packages.

4. Install required php7.2 pacakges: Note that this time this installed BOTH php7.2 and 7.3 which it did NOT do the last time with the exact same command. Odd one. Even stranger is that even this did NOT pull in that openssl1.1.

5. Chose php 7.2 using "update-alternatives --config php"

6. Comments out the new repo.

7. Ran "apt update"

After the above of course the regular updates won't install that new openssl. However I'm still confused as to why it's even there if it wasn't pulled in by any of this. While I haven't tried this yet...and someone can correct me if this is wrong...I believe I could update just php in the future by doing the following:

1. Uncomment the new repo.

2. apt update

3. apt-get install --only-upgrade "php7*"

4. Comment out the new repo.

3. apt update

I going to test that php install and see if I run into any issues as a result of not having that openssl1.1. Still don't get why that's there.

Tom

i'm talking about php5.6 in jessie, php7.0 in ascii/stretch (official distro php packages) : https://secure.php.net/eol.php
they do get security updates through distro repos still, but some web-apps are already complaining about old php versions.

Now I see where I was confused. I had it in my head that ascii came with 7.2, but I take that it's official distro packages are 7.0. Then I take it that the only way to get >= 7.2 from official repos would be to wait for Beowulf? We actually couldn't use 7.0 in any case. 7.1 wound be a minimum.

Regarding that openssl, I believe you're correct about something requiring it, however if that's the case it must be something in php 7.3, because nothing in 7.2 needed to pull it in. However the regular update/upgrade process of course wants to pull it in as long as the repo is active.

Thanks!
Tom

xinomilo wrote:

note: jessie/stretch/ascii php versions are already officially EOL, and will also be leaving sury repo soon...

I didn't see this until today. I'm totally confused as to what you're saying is EOL..."jessie/stretch/ascii php versions"? I must be missing something. Are you just referring to versions on sury? Surely ascii php 7.2 isn't EOL for example.

i'm talking about php5.6 in jessie, php7.0 in ascii/stretch (official distro php packages) : https://secure.php.net/eol.php
they do get security updates through distro repos still, but some web-apps are already complaining about old php versions.

note: jessie/stretch/ascii php versions are already officially EOL, and will also be leaving sury repo soon...

I didn't see this until today. I'm totally confused as to what you're saying is EOL..."jessie/stretch/ascii php versions"? I must be missing something. Are you just referring to versions on sury? Surely ascii php 7.2 isn't EOL for example.

Also to be clear, in the cases where I might want to do this, upgrading to ascii or compiling from source won't be an option. This would be on virtual appliances in the field in production. Worst case we might port them to a new VM running ascii I suppose.

Thanks
Tom

the other solution is to build from source. but some people don't want to install *-dev packages on production machines, and others simply can't/don't know how to compile. (btw, reproducible builds is a great project..)
anyway, it's all about choices/user freedom, i think.. you have all these options available, proceed with "caution"..

2 more cents on this topic

My2Cents

KatolaZ

Thanks!
Tom

EDIT: Just to note: I just testing and commenting out that repo and doing and update and dist-upgrade doesn't downgrade that openssl version. Also, after reading the home page at https://deb.sury.org/ it certainly appears that the repo is managed by someone who knows what they're doing.

yes i also think it's a trusted source. sury is a debian developer (packaging php among others) and also involved in PHP : https://qa.debian.org/developer.php?ema … debian.org
also using his stretch/ascii repo for newer php7.1 & php7.2 on some servers. and in some cases php5.6 branch, since php5 is not avaiable in stretch/ascii.

and you can pin a package to specific version/repo if you like. check : https://wiki.debian.org/AptPreferences

I think the answer is no, but is there any way to block a specific package from an enabled repository?

EDIT: Just to note: I just testing and commenting out that repo and doing and update and dist-upgrade doesn't downgrade that openssl version. Also, after reading the home page at https://deb.sury.org/ it certainly appears that the repo is managed by someone who knows what they're doing.

Thanks!
Tom

That "unknown" tag might be the result of running lsb_release -sc.

If you want to recover, whilst keeping php 7.2, it might work that you comment out the repository point in that file, then do an update followed by a dist-upgrade. Or just comment it out without dist-upgrade so as to avoid pulling in stuff from there in the future.

https://tecadmin.net/install-php7-on-debian/

...which describes installing from this source:

https://packages.sury.org/php/README.txt

That all seems to have worked fine. One oddity was that we required php-pear and php-log which apparently needed to pull in php5-common php5-sqlite which had been removed, though that doesn't seem to have affected anything.

The one aspect of it that bothered me a little was that one of the updates that that repo included was openssl. Here are the upgradable packages after that an "apt update" with that source:

apt list --upgradable
Listing... Done
libgd3/unknown 2.2.5-5+0~20190119054525.2+jessie~1.gbp911a4a amd64 [upgradable from: 2.1.0-5+deb8u12]
libpcre3/unknown 2:8.42-1+0~20190203125145.5+jessie~1.gbp79d75d amd64 [upgradable from: 2:8.35-3.3+deb8u4]
openssl/unknown 1.1.1a-2~20190131152532.8+jessie amd64 [upgradable from: 1.0.1t-1+deb8u10]
php-pear/unknown 1:1.10.8+submodules+notgz-1+0~20190219091008.9+jessie~1.gbp1a209a all [upgradable from: 5.6.40+dfsg-0+deb8u1]

As far as I could tell, it didn't appear that that openssl version was a dependency of any of the php stuff, and it didn't get installed until I expressly did an upgrade. Everything appears to be fine but I was curious as to that update, especially to something as important as openssl. I'm also curious as to those packages all reporting /unknown. Is that expected, and is there anything that can change that?

Thanks in advance if anyone knows something about any of that!

Tom