On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:

# apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
plasma-workspace : Depends: gdb-minimal but it is not going to be installed or
gdb
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

This problem isn't because of apt, the problem is that gdb-minimal/gdb dependencies cannot be satified. A full-upgrade is the equivalent of a dist-upgrade which will remove packages to resolve the dependencies. The problem you are facing is the t64 transition[1][2] where not all packages are transitioned.

My advice to you is: don't expect full-upgrade to work until the transitioning is done. You can do `apt upgrade' without too much hassle. If you feel like it you can inspect individual upgrades possibilities via `apt list --upgradable' and upgrade each package individually. That has worked well for me in the past week with aptitude, but it requires going through many offered solutions.

I've seen other users are experimenting the same issue: https://groups.google.com/g/linux.debian.user/c/7gpQImSH-Cs

This seems to be an more of an actual issue where dependencies are declared but apt doing something weird. But that is an issue on bookworm where we aren't getting poluted results because of a transitioning. It differs from yours because your apt output says "gdb-minimal but it is not going to be installed or gdb" so apt sees the alternative, but cannot install it either. IMHO, that should
be filed as a seperate bug against apt on bookworm. And if possible checked on testing as well. FWIW, I can reproduce it on bookwork with apt, apt-get and aptitude, where the latter offers a solution to install gdb and not deinstall plasma-workspace.

I don't know why plasma-workspace depends on gdb

I don't know either and that question should be redirected to the plasma-workspace maintainer.

Cheers,
Wesley

[1] https://lists.debian.org/debian-devel-announce/2024/02/msg00000.html
[2] https://www.reddit.com/r/debian/comments/1b2ncdn/64bit_time_t_transition_in_progress_in_unstable/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Miguel,

On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote:

This problem isn't because of apt, the problem is that gdb-minimal/gdb
dependencies cannot be satified. A full-upgrade is the equivalent of a
dist-upgrade which will remove packages to resolve the dependencies. The problem you are facing is the t64 transition[1][2] where not all packages

are

transitioned.

I haven't detected any "gdb | gdb-minimal dependencies that can't be satisfied at this point. Everything seems to be OK with those packages.

No, there is (or was) something going on with the dependencies of gdm-minimal for sure. I think it is related to libdebuginfod1, which has a t64 variant. This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64 depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, the former having a relative high count of reverse dependencies.

My advice to you is: don't expect full-upgrade to work until the

transitioning

is done.

You nail it here! I have managed to upgrade package by package but it is a tedious process until the whole transition is completed.

Some of them yes, but often after doing one, you can use `apt upgrade' to
see if it resolved other problems (which in my case it does from time to time).

But "apt upgrade"
should not remove any packages according to its documentation (man apt)

That is correct, but you were executing full-upgrade:

On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:

# apt full-upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Error!
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Why is this t64 upgrade working then as it is removing deprecated packages for *t64 packages?

I do not know, at times I'm also wondering why it doesn't do it, but I didn't take time to look at the code to understand what the resolver is doing. Also, it was sort of expected. I think we can probably solve this is a more controlled manner. With the current t64 transitioning in unstable it is difficult to track down. Many updates so the situation now may differ from the situation in an hour from now.

This seems to be an more of an actual issue where dependencies are

declared but

apt doing something weird. But that is an issue on bookworm where we

aren't

getting poluted results because of a transitioning.

I'm glad you were able to replicate in bookworm (stable) it but I don't
think (at least in this case) it is related to the t64 transition. Same errors on both distributions and I checked that gdb dependencies were satisfied in unstable (I don't have a system running stable).

I disagree (or agree) to some extent. The gdb-minimal has been held back on my system for a long time. I removed it after I saw it was a remnant of a KDE experiment I did. The fact that I can install it now is a change from a couple of days ago. The bug may be the same, but with how unstable it is now with
this big transition, it's wise to leave it where we are now and break it down into a more controlled reproduction path, where we don't have so many moving pieces.

Appreciate your support.

Yw and good luck!

Cheers,
Wesley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Miguel,

On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:

I do not know, at times I'm also wondering why it doesn't do it, but I

didn't

take time to look at the code to understand what the resolver is doing.

Also,

it was sort of expected. I think we can probably solve this is a more controlled manner. With the current t64 transitioning in unstable it is difficult to track down. Many updates so the situation now may differ

from the

situation in an hour from now.

Yes, it is confusing for me too. Without considering this t64 migration, “apt upgrade” should *NOT* remove any package (just upgrading a package to
a newer version or install new dependencies). But it is removing packages right now! i.e. again, with this t64 migration, it makes the old libraries
to be uninstalled and install the new *t64 version.

Any thoughts why “apt upgrade” is removing packages even when documentation
says it shouldn’t? or is it a bug?

You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As said earlier, full-upgrade does indeed remove packages to be able to perform an upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt doing something wrong when it isn't :)

Cheers,
Wesley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:

Yes, it is confusing for me too. Without considering this t64 migration, “apt upgrade” should *NOT* remove any package (just upgrading a package to
a newer version or install new dependencies). But it is removing packages right now! i.e. again, with this t64 migration, it makes the old libraries
to be uninstalled and install the new *t64 version.

Any thoughts why “apt upgrade” is removing packages even when documentation
says it shouldn’t? or is it a bug?

If "apt upgrade" is saying that it removes packages, that is a bug, yes.

Please run: apt upgrade -s -o Dir::Log::Solver=/tmp/apt-upgrade-bug.edsp.xz
(as normal user; the -s enables simulation so nothing bad can happen)

That will create a /tmp/apt-upgrade-bug.edsp.xz file (a few MBs big) you
can sent to me (it might be too big for a bug and/or the mailinglist).
That file contains information about all packages currently available to
you and which of them you have installed – as that changes quiet often
and its near impossible to reproduce a problem, especially while a big transition is underway, otherwise.

If that package-removing upgrade happened in the past, you can look it
up in /var/log/apt/history.log – far less details and harder to
reproduce, but at least some chance…


I do have to note that I am somewhat dubious through. I have heard that
claim quiet often recently and so far it turned out not to be an "apt
upgrade" invocation in the end, confusing it with autoremove remarks or
didn't expect that some non-t64 and t64 packages became co-installable…
but never say never.


Best regards

David Kalnischkies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmXvNMwACgkQMRvlz3HQ eIO0rw/+I2ljIk4V59RK4QAIt/Xhwbxe2FPHQhKdtJqKgCWCGe5hIknukoflsUbu naa0FGjTgW6labdg3vKI0AGTibNLGOPaQ03VzllTdZHUfyOWkt33Ll+T/PmFDV20 J/r/YqW1oobOpL6Bgn67PPHD5VA/Gk/vVo8zlQT75+bR78wlNGJxCyejPH6TvPPY Goy4hafMtqVks62S6GxXKsiKPXUYHpH0AOilGtMXVa4hHHutFKG2yY2rYTMvvJ64 0q50GOI61pmwZmrsVXvrEinNz/ouSckbCvznc0rhEfBLDQxCENYZGNSSv4vee0a6 5j2k2xHA/Pba3cVuEto5fm4/TrgQdy4bT9sHDIZ1+M1CqSMbSSf92IKQAVksDIpr xYHcpT9OYdK+tnO1jQpEYvFZB85yrL7qYIxldL1PUXl7OYvnNLG6PQNepSiYQBU+ yeRyQ/a+VA7w/T4AzLy+jm0FWVN0DDMYpTS8gJxX/G5nIAtwygGpdBz0VQce+kuj 7EgE2fB/IvwtV2O1sQnl67/67S6wkJf/f/p6DSO0323CKW7NweZ42J1IlzQMT+B7 OCBoY8d9sjx8ZUMNs9m3xnvuGyvt6oMPMBmsvw8oM5JA2H4qhTp5Fc/QWZFDs4MQ y5XtuvNUtr0yV8hgU/SNqdwxlNfMVOV0XmVnZ9hRkbFOELXn7mE=
=4XpL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 11, 2024 at 10:48:53PM +0100, Miguel Angel Rojas wrote:

Hi Wesley, David,

You keep saying `apt upgrade' yet your command was `apt full-upgrade'.

Yes, maybe it didn't express itself properly. After your suggestion about
not using "apt full-upgrade" during this t64 migration, I followed your advice and used only "apt upgrade" for individual upgrades. I was referring to this comment you made below:

Ah, and I meant upgrading as individually installing packages ala: `apt install foo'. I get the confusion now :)

Now, If I type"apt upgrade" doesn't give me any option to update anything:

Ok, that is expected behaviour.

But, in some situations, as you mentioned, individual package upgrades can work and remove some problems. So what I did was to try some "apt upgrade"
on individual packages from that list. This time I try the ppp package:

# apt upgrade ppp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
linux-headers-6.6.15-amd64 linux-headers-6.6.15-common linux-image-6.6.15-amd64 linux-kbuild-6.6.15
Use 'apt autoremove' to remove them.
The following packages will be REMOVED: <------- PACKAGE TO BE REMOVED
libpcap0.8
The following NEW packages will be installed:
libpcap0.8t64

[snip]

The following packages will be upgraded:
ppp
1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded.
Need to get 511 kB of archives.
After this operation, 15.4 kB disk space will be freed.
,

As you can see here, I'm typing "apt upgrade ppp" and it removes a package
in this case: libpcap0.8 (sometimes more packages are removed).

Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which contradicts the specification).

I see. It looks like `apt upgrade <package>' behaves as `apt install <package>'. Which (to me) is unexpected behaviour, as the man page is quite clear on its behaviour (man 8 apt-get):

upgrade
upgrade is used to install the newest versions of **all** (emphasis mine)
packages currently installed on the system from the sources enumerated in
/etc/apt/sources.list.

It shouldn't accept the arguments you feed it, apt-get has the same
"feature". And with an install you do remove packages to satisfy the deps.

Cheers,
Wesley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:

I see. It looks like `apt upgrade <package>' behaves as `apt install <package>'. Which (to me) is unexpected behaviour, as the man page is

quite

clear on its behaviour (man 8 apt-get):

Well, clearly it shouldn’t. To begin with, “apt install” should mark a package as manual installed while “apt upgrade” shouldn’t (my assumption).
And you’re right that “apt install” can remove a package if needed to satisfy dependencies.

On top of that, documentation clearly states that “apt upgrade” should not
remove any package, but it does when you specify an individual package to upgrade.

If this is not the expected behavior, maybe this is a bug (unless I am missing something here).

I do not know what the bug here is, it could be one of these options:

1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
doesn't. The behaviour needs to change to not accept packages.

2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
where the docs state it doesn't. The behaviour need to change to not remove
any packages. There is a small edge case where you can say: `apt upgrade foo
bar-'. Technically, it shouldn't remove packages, yet you want and instruct
it to remove bar.

FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade foo'. It does remove packages when you call `aptitude full-upgrade foo'. It also removes bar when you run `aptitude safe-upgrade foo bar-'.

I'll leave this for the maintainers to answer.

Cheers,
Wesley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Mar 12, 2024 at 11:40:01AM +0100, Julian Andres Klode wrote:

On Mon, Mar 11, 2024 at 10:12:33PM -0400, Wesley Schwengle wrote:

I do not know what the bug here is, it could be one of these options:

1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
doesn't. The behaviour needs to change to not accept packages.

2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
where the docs state it doesn't. The behaviour need to change to not remove
any packages. There is a small edge case where you can say: `apt upgrade foo
bar-'. Technically, it shouldn't remove packages, yet you want and instruct
it to remove bar.

The behavior is correct if potentially unexpected, but it should be documented better.

Thanks, it was option 3) Works as intended, documentation needs to be updated.

FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade
foo'. It does remove packages when you call `aptitude full-upgrade foo'. It also removes bar when you run `aptitude safe-upgrade foo bar-'.

That is an entirely different command; `aptitude safe-upgrade foo`
upgrades (only) `foo`, whereas `apt upgrade foo` first does the normal install argument handling and then runs an upgrade, so `foo` could also
be a new package that is not currently installed to hint the solver if
it is unable to find a solution.

Ahhh. I was under the impression that they had a similar intent.

On a related note: While debugging I also noticed apt's update and apt-get's update are also slightly different. apt-get will not allow for new packages to be installed whereas apt's version does allow this. You get apt's behaviour with the --with-new-pkgs switch in apt-get's version of upgrade.

Cheers,
Wesley

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)