On 2024-04-30 10:58, Brad Rogers wrote:
On Tue, 30 Apr 2024 09:51:01 -0400
Gary Dale <g...@extremeground.com> wrote:
Hello Gary,
Not looking for a solution. Just reporting a spate of oddities I've
encountered lately.
As Erwan says, this is 'normal'. Especially ATM due to the t64
transition.
As you've found out, paying attention to removals is a Good Idea(tm).
Sometimes those removals cannot be avoided. Of course, removal of
'library' to be replaced with 'libraryt64' is absolutely fine.
If the upgrade wants to remove (say) half of the base packages of KDE,
waiting a few days would be prudent. :-D
You may also notice quite a few packages being reported as "local or
obsolete". This is expected as certain packages have had to be removed
from testing to enable a smoother flow of the transition. Many will
return in due course. I do know of one exception, however; deborphan
has bee removed from testing and, as things stand, it looks like it
might be permanent - I fully understand why, but I shall mourn its
passing, as I find it to be quite handy for weeding out cruft.
Yes but: both gdb and nfs-client installed fine. Moreover, the
nfs-client doesn't appear to be a dependency of any of the massive load
of files updated lately. The gdb package however is but for some reason
apt didn't want to install it.
The point is that apt didn't handle the situation reasonably. If it
wanted a package that was installable, should it not have installed it?
And while nfs-client isn't a dependency of other installed packages, why
should autoremove remove it? It's status of not being a dependency
didn't change. There are lots of packages that aren't depended on by
other packages that I have installed (e.g. every end-user application).
Shouldn't autoremove only offer to remove packages that used to be a
dependency but aren't currently (i.e. their status has changed)?
