Page 1 of 1

Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-20 10:17
by archygriswald
I am in the process of upgrading to Bullseye.
When doing

Code: Select all

apt full-upgrade
I see that apache2 is going to be installed. I do not want apache on my system, I have nginx already running.

How can I prevent this?

Is it safe to do

Code: Select all

apt-mark hold apache2, apt-mark hold apache2-bin, etc.
and then do the upgrade?


(( Also: I see many packages that the upgrade wants to install, like libdrm & some graphics drivers.
This is frustrating because if I did not have them on buster then why is the upgrade trying to install them for bullseye? This is an internet facing machine that I want to keep as minimal and clean as possible.
Why is Debian doing this? ))

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-20 13:03
by arzgi
You can remove any package later.

Easier might be take backups (what you should have done anyway) of important data, and install Bullseye, ie. don't upgrade.

I have separate partition for /home, the installer can leave it as it is. Though there are some caveats, like old configs for newer software. But that would be the case also after upgrading.

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-20 14:10
by craigevil
I would suggest reading the Release Notes:
https://www.debian.org/releases/bullseye/releasenotes

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-20 15:25
by fabien
archygriswald wrote: 2022-05-20 10:17When doing

Code: Select all

apt full-upgrade
I see that apache2 is going to be installed. I do not want apache on my system, I have nginx already running.

How can I prevent this?
The first step is finding what package pulls apache2. You can add Debug::pkgDepCache::AutoInstall option to your initial command.
'man 5 apt.conf' excerpt:
Debug::pkgDepCache::AutoInstall
Generate debug messages describing which packages are being automatically installed to resolve dependencies. This corresponds to the initial auto-install pass performed in, e.g., apt-get install, and not to the full apt dependency resolver; see Debug::pkgProblemResolver for that.

Code: Select all

apt -o Debug::pkgDepCache::AutoInstall=1 -sV full-upgrade
If you don't know how to asses the result, you can paste here the relevant part.
archygriswald wrote: 2022-05-20 10:17Is it safe to do

Code: Select all

apt-mark hold apache2, apt-mark hold apache2-bin, etc.
and then do the upgrade?
According to the release notes, it is not safe:
It is desirable to remove any holds before upgrading. If any package that is essential for the upgrade is on hold, the upgrade will fail.
archygriswald wrote: 2022-05-20 10:17(( Also: I see many packages that the upgrade wants to install, like libdrm & some graphics drivers.
This is frustrating because if I did not have them on buster then why is the upgrade trying to install them for bullseye? This is an internet facing machine that I want to keep as minimal and clean as possible.
Why is Debian doing this? ))
Because package dependencies change over Debian versions. Sometimes packages need new dependencies, sometimes libraries or packages are split into several parts.
Some new dependencies are "only" recommended (field Recommends in package descriptions) and you can ponder whether to keep them.
It is also important to minimize manually installed packages: this means marking as much as possible packages as automatically installed. For instance, if a library is marked as manually installed, the upgrade process will keep it (and its dependencies) even if it is now useless.
In my experience, newer Debian versions always take more disk space and pull new packages though.

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-21 16:40
by archygriswald
Ok, doing

Code: Select all

apt -o Debug::pkgDepCache::AutoInstall=1 -sV full-upgrade
results in:

Code: Select all

    [...]
    Installing php7.4 as Hängt ab von of php
    Installing libapache2-mod-php7.4 as Hängt ab von of php7.4
      Installing php7.4-cli as Hängt ab von of libapache2-mod-php7.4
        Installing php7.4-json as Hängt ab von of php7.4-cli
        Installing php7.4-opcache as Hängt ab von of php7.4-cli
        Installing php7.4-readline as Hängt ab von of php7.4-cli
      Installing [b]apache2-bin[/b] as Hängt ab von of [b]libapache2-mod-php7.4[/b]
        Installing libapr1 as Hängt ab von of apache2-bin
        Installing libaprutil1 as Hängt ab von of apache2-bin
        Installing libaprutil1-dbd-sqlite3 as Hängt ab von of apache2-bin
        Installing libaprutil1-ldap as Hängt ab von of apache2-bin
        Installing libjansson4 as Hängt ab von of apache2-bin
      Installing [b]apache2 as Empfiehlt of libapache2-mod-php7.4[/b]
        Installing apache2-data as Hängt ab von of apache2
        Installing apache2-utils as Hängt ab von of apache2
        [...]

(sorry for the stupid german language snippets, "Hängt ab von" means depends, "Empfiehlt" means recommends)

When I add --no-install-recommends it gives:

Code: Select all

Installing php7.4 as Hängt ab von of php
    Installing libapache2-mod-php7.4 as Hängt ab von of php7.4
      Installing php7.4-cli as Hängt ab von of libapache2-mod-php7.4
        Installing php7.4-json as Hängt ab von of php7.4-cli
        Installing php7.4-opcache as Hängt ab von of php7.4-cli
        Installing php7.4-readline as Hängt ab von of php7.4-cli
      Installing apache2-bin as Hängt ab von of libapache2-mod-php7.4
        Installing libapr1 as Hängt ab von of apache2-bin
        Installing libaprutil1 as Hängt ab von of apache2-bin
        Installing libaprutil1-dbd-sqlite3 as Hängt ab von of apache2-bin
        Installing libaprutil1-ldap as Hängt ab von of apache2-bin
        Installing libjansson4 as Hängt ab von of apache2-bin
So adding --no-install-recommends, I could live with that, only having package apache2-bin lying around there.
But how the hell can php(7.4) recommend a full apache to be installed while having nginx already on the system??? (nginx was installed via standard repo and will be going to be updated when doing the full-upgrade)

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-21 20:21
by LE_746F6D617A7A69
archygriswald wrote: 2022-05-21 16:40 But how the hell can php(7.4) recommend a full apache to be installed while having nginx already on the system???
Actually it's not PHP7.4 but a libapache2-mod-php7.4 which is part of apache suite -> it depends on apache2
You've probably installed it Yourself as an "extension" for PHP functionality (just guessing) -> try to uninstall all apache2 related packages before upgrading the OS.
Of course, this can be also an effect of using foreign repositories - check Your sources.list

Definitely, You *should not* use the --no-install-recommends option - this will break a lot of packages.
I would say that this option is mostly useful for debugging dependecies - normal users shouldn't use it, excluding special cases, where the user is expected to know *exactly* the consequences.

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-21 21:43
by archygriswald
I think I might got it.

As one can see on https://packages.debian.org/bullseye/php7.4, a dependency of php7.4 is libapache2-mod-php7.4 OR php7.4-fpm.
(php-fpm was on my system before and it is going to be updated now)

So when I do

Code: Select all

apt -o Debug::pkgDepCache::AutoInstall=1 -sV full-upgrade libapache2-mod-php7.4-
apt runs through without errors.
Meaning that I tell apt to not install libapache2-mod-php7.4. The dependency is still met as php7.4-fpm is there. And as a result NO apache packages are installed with the upgrade, just like I wanted.

I think I will do the upgrade tomorrow in that way.

(Still, I think it is kind of a bug that apt wants to install apache as a result of pulling libapache2-mod-php7.4 which is not really a dependency of php7.4 because I already hat php-fpm on my system.)

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-22 00:40
by fabien
archygriswald wrote: 2022-05-21 21:43So when I do

Code: Select all

apt -o Debug::pkgDepCache::AutoInstall=1 -sV full-upgrade libapache2-mod-php7.4-
apt runs through without errors.
Meaning that I tell apt to not install libapache2-mod-php7.4. The dependency is still met as php7.4-fpm is there. And as a result NO apache packages are installed with the upgrade, just like I wanted.
I tried it in a VM and php7.4-fpm was not there, leading to a broken php7.4 package (without apt complaining, strange).
The right command was:

Code: Select all

apt -sV full-upgrade php7.4-fpm
archygriswald wrote: 2022-05-21 21:43(Still, I think it is kind of a bug that apt wants to install apache as a result of pulling libapache2-mod-php7.4 which is not really a dependency of php7.4 because I already hat php-fpm on my system.)
That's because php7.4 is treated as new package, not an upgrade of php7.3, hence its default dependency libapache2-mod-php7.4 being selected. But it's rather a particular case I don't remember having seen before.

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-22 13:14
by archygriswald
Upgrade successful!
I am on 11.3 now, nginx & php7.4 are running, and not a single apache package on my system.
It was sufficient to

Code: Select all

apt full-upgrade libapache2-mod-php7.4-
Dependencies for php7.4 were still met because of php-fpm.

Thanks to all for looking into my problem. Especially @fabien, thank you so much, you helped me a lot!!

Re: Buster ==> Bullseye Upgrade: Don't install unwanted packages

Posted: 2022-05-22 16:46
by fabien
archygriswald wrote: 2022-05-22 13:14Dependencies for php7.4 were still met because of php-fpm.
I didn't grasp that php-fpm was actually a package (a dependency package which depends on latest stable PHP version, i.e. php7.4-fpm). So in this case in my opinion you're right: the resolver should select php7.4-fpm as an alternative. Technically, the problem is probably that php7.4 dependencies are treated before php-fpm that introduces the new php7.4-fpm. Adding php7.4-fpm to the command lines puts it on top of dependencies resolution and solves the problem in a way that I think is better for the resolution process, but it probably requires

Code: Select all

apt-mark auto php7.4-fpm
in the end to ensure proper package status (I haven't actually tested a real upgrade).
Even better would be:

Code: Select all

apt -sV full-upgrade php-fpm
since php-fpm can be more safely manually installed.
Your solution also works well, but may be a bit risky as one can imagine a case where libapache2-mod-php7.4 would be needed by another package but barred to install. Real cases are to be carefully pondered.
archygriswald wrote: 2022-05-22 13:14Thanks to all for looking into my problem. Especially @fabien, thank you so much, you helped me a lot!!
With great pleasure. You're welcome! Interesting problems by the way, thanks.