- This topic has 22 replies, 5 voices, and was last updated Aug 7-4:13 am by Anonymous.
-
Posts
-
Xaver
As long as ‘apt full-upgrade’ will remove packages that you want to keep, it does no harm to use ‘apt update’ instead. But you should never use ‘apt-get upgrade’ in sid. The obsolete stuff will be removed, when ‘apt full-upgrade’ will finally not damage your system anymore.
Further down in the same thread @melemarker does explain this (and @piper dissents).
If a system has not been ugraded for a while (i.e. the siductions ISOs) an ‘apt full-upgrade’ might ruin it. Sometimes you must run ‘apt upgrade’ and ‘apt –fix-broken install’ for several times, before you can safely perform ‘apt full-upgrade’.
Therefore ‘apt upgrade’ should work properly. That is essential.
Anonymous
As long as ‘apt full-upgrade’ will remove packages that you want to keep, it does no harm to use ‘apt update’ instead.
@melmarker always says that people with learning resistances cannot be helped…
anti and also i have told/shown you that we don’t have libsystemd0 on our systems.
You have not even explained here why it is on your “sid”…Xaver
@male
So far the antiX forum has been exploratory and very constructive.
Usually people do not hurl insults at eachother.By the way: There is no libsystemd0 on my system nor have I ever mentioned that.
- This reply was modified 3 years, 9 months ago by Xaver.
Yeah, well, excuse me. I just dreamed that.
Xaver
current state:
‘# apt full-upgrade’ works fine.
‘# apt-get upgrade’ would work as well (not advisable in sid).
‘# apt-get upgrade –with new pkgs’ or ‘# apt upgrade’ still generate this error message:The following packages have unmet dependencies: libelogind0 : Conflicts: libsystemd0 libelogind0:i386 : Conflicts: libsystemd0BUT: There are no new packages to be installed! Ihave just performed a full-upgrade.
The solution is simple:
The conflict is caused by udisks2. The latest sid version is 2.8.4-1, whereas the installed antiX-sid 0nosystemd1 version is 2.8.2-1.
If I set udisks2 on hold, ‘# apt upgrade’ will work without problems.How come, that only ‘upgrade’ is affected, but not ‘full-upgrade’?
- This reply was modified 3 years, 9 months ago by Xaver.
- This reply was modified 3 years, 9 months ago by Xaver.
anticapitalista
Because when running sid you should only really use apt-get dist-upgrade (with caution) as new libs may need to be installed and old ones removed, while apt-get upgrade never removes packages
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Xaver
Thanks. I know, that regular system upgrades should be done by ‘full-upgrade’ If upgrades of software in sid require new packages, ‘apt-get upgrade’ could make some software or even the whole system unusable.
But with ‘apt upgrade’ this cannot happen, because it includes required new packages. So it is safe to use it in certain situations and can be very helpfull, when full-upgrade will remove lots of productive software. It works as if you had put the problematic packages on temporary hold.
But all this does not answer my question: How can a package like udisk2, that is kept back, block ‘# apt upgrade’, while actually there are no packages to be installed right now. On top it is mysterium to me, why then ‘# apt full-upgrade’ is not blocked as well.
The intention of my question is a deeper understanding of the system.The practical solution for such cases is simple: Watch out for libsystemd0 packages, which have not been upgraded yet. Put them on hold, untill the upgrade is available.
The intention of my question is a deeper understanding of the system.
I’ve said it before: man apt
- You must be logged in to reply to this topic.
