[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#982797: apt: Advice requested for PHP deps



Control: reassign -1 php8.0 8.0.2-1
Control: retitle -1 phpY.Z: do not switch to apache2-mod on major upgrade

Hi,

On Sun, Feb 14, 2021 at 04:22:37PM +0100, Olaf van der Spek wrote:
> This is a request for advice for dependencies of PHP packages. See the related issue @ https://github.com/oerdnj/deb.sury.org/issues/1533

We do not usually get such requests via bugreports as we are not the
party who will be able to do anything about the reports itself – even if
it turns out to be a colossal bug in apt, the packages still needs to
make due with the apt version from stable. As such I am reassigning to
php8.0 (reason further below) so that this isn't rotting away as
unactionable in apts staggering heap of open reports.

Next time report it against a package you suspect might be involved. The
maintainers will know their packages better than we could and either
figure something out themselves or can ask us via a CC. A friendly mail
works also for third-party repos and/or derivatives.


> The goal is to avoid a situation where apt wants to install a second web server:
> In this case lighttpd / php7.4-fpm was installed already.

Next time please describe more the state you are in, the state apt wants
to bring you into vs. what you expected it to do as we will otherwise
have to resort to guesswork (or more likely ignoring it until we might
have more time for guessing "later" which usually translates to never).

So, my guess is that you have (among other things) php and php7.4-fpm
installed and you have a third-party repo (sury) which gives you a new
version of php which depends now on php8.0 (instead of php7.4) which in
turn depends on "libapache2-mod-php8.0 | php8.0-fpm | php8.0-cgi" and
apt chooses to install libapache2-mod-php8.0 rather than php8.0-fpm
which you would have preferred given you have php7.4-fpm installed.
Am I right? (Hopefully, as I will assume I am in the following)

(I will assume that what we have in experimental is what the repo is
 shipping and will work with that as I have that data readily available.
 It also gives me a place to reassign this bug to…)


While that seems like a no-brainer for a human reading this apt has
literally no idea that the packages php7.4 and php8.0 or php7.4-fpm and
php8.0-fpm are related. For apt they are completely distinct packages
which just happen to be close together if sorted by name [0].


So lets see about establishing relations so that apt can understand.
For this, you need additional packages installed though, so lets first
see to it that a user will usually have them:

For this we will add "Recommends: libapache2-mod-php (= X) | php-fpm
(= X) | php-cgi (= X)" to the php package. X is here the binary
version of the package which is easy as they are all built from the
same source package.

That isn't a huge change as those are just metapackages depending on
a specific versioned package the versioned phpY.Z package will depend on.
In fact, in your example output we see php-fpm is already installed.


Okay, after this amuse-gueule, lets move on to the main dish: phpY.Z

Lets first consider using this:
Package: phpY.Z
Depends: libapache2-mod-php (= X) | php-fpm (= X) | php-cgi (= X)

X here is again the version of those packages depending on the versioned
variants for phpY.Z. So, just as above, but phpY.Z is a different source
package, so that is some tight coupling! They are metapackages though,
so they don't change that often and that could be manageable. It could
be relaxed slightly by using indirection via versioned provides (I will
leave this as an exercise to the reader as its mostly busywork to write
it down here) as we do not have (easy) and-groups in dependencies.

Congratulations, we solved the problem! Now, if you had a previous
version of php installed and a new one becomes available apt will
recognize that php-fpm is installed already, but in an old version, so
it will upgrade that which will lead to the install of phpY.Z-fpm instead
of us ending up with (also) libapache2-mod-phpY.Z installed.

We have another problem now though: Different phpY.Z versions aren't
co-installable anymore as they will require different exact versions of
those metapackages! Oh, dear supercow, how are we gonna solve that?!?


(pause for effect: Give yourself a minute and you will figure it out)


Adding more alternatives solves this, of course! ☺ In fact, we just have
to bring back those the phpY.Z package had before for a glorious:

Package: phpY.Z
Depends: libapache2-mod-phpY.Z | phpY.Z-fpm | phpY.Z-cgi |
         libapache2-mod-php (= X) | php-fpm (= X) | php-cgi (= X)

Now due to php-fpm apt will install phpY.Z-fpm which will satisfy this
dependency even after php-fpm changed to a different php version (it
also means a version desync with X isn't as bad as it was before as the
later three are only used in a brief moment during a major upgrade).


That doesn't solve the related but harder problem of wanting
a non-default phpY.Z leading to a phpY.Z-fpm install if php-fpm is
installed, but for that we would need non-existent conditional
dependencies[1].

I also have to note that the described behaviour of apt upgrading
php-fpm in this or-group first is a bullseye feature (well, 2.1.0 to
be exact, so roughly a year old). With apt from buster that will not
(always) work, but the failure mode is the same as before so that might
be just fine.


Best regards

David Kalnischkies

[0] Ironically, at least the upgrade case would work if you sort php-fpm
before php as apt doesn't reason about all dependencies at once but for
each package on each dependency in turn and so we have to tip it off to
check php-fpm out earlier by establishing an explicit relation. It is
needed either way for the explicit install request though.

[1] The following would work with current apt, but I have no idea how
other parts of the infrastructure would react for binary packages. We
"joke" about it whenever someone demands conditional dependencies, but I
have never seen it used for real in the archive yet.
On source packages it would implode directly as alternatives do not work
that way there. Reading and understanding the following stanza is a bit
like becoming a Necromancer – you gain power in exchange for parts of
what makes you a normal human (as far as a Debian contributor can be
considered that to begin with), but if power is what you desire…

Package: phpY.Z
Depends: libapache2-mod-phpY.Z | phpY.Z-fpm | phpY.Z-cgi | php-fpm | php-cgi,
         phpY.Z-fpm | libapache2-mod-phpY.Z | phpY.Z-cgi | libapache2-mod-php | php-cgi,
         phpY.Z-cgi | libapache2-mod-phpY.Z | phpY.Z-fpm | libapache2-mod-php | php-fpm,
         libapache2-mod-phpY.Z | phpY.Z-fpm | phpY.Z-cgi

Attachment: signature.asc
Description: PGP signature


Reply to: