Ingnore Pkg but system gets "currupt" anyway

schnedan · 2025-06-11 10:09:06

2-3 weeks ago there was a huge problem with vmware and mesa.
It also affects virtualbox as vmware's graphics driver is the new standard.

so i set mesa and the vmware xorg driver to be ignored... and I was fine again

today I updated and ended in sddm to fail: black screen (short version of sory)
installed lightdm: black screen, blinking cursor. (short version of sory)

With the logs of lightdm I figured out: old mesa, new clang/llvm --> incompatible

downgraded all clang/llvm

now sddm again works. :-) I am fine again,... until I started my usual programms:

QTCreator? also fails: needs new clang/llvm , but I have downfgraded,... so I also downgraded QTCreator

...

Long story short:

We need:
Ingnore Pkg with dependencys resolved: mesa blocked? needs clang/llvm, so all other clang/llvm based pkg need to be blocked too!

What would have helped me to resolve such problems much faster:
can we with pacman get what pkg have been installed by last update, today, last 1,2,5,... days?
can we check if any of these pkg have a dependency with some other package?
can we rollback a system to a point before a certain update (last one, the one 2 days ago,..) ?

If not, and you are an arch developer:

We need such features to fast recover pkg errors!
I use 2+ Arch VMs at work and I need em to be running. Any system management time is wasted time at work!
I would save a lot lot lot of time if I could resolve such issues better.

Thx for reading

V1del · 2025-06-11 10:13:06

Drop all IgnorePkg attempts, remove xf86-video-vmware, update your entire system.

xf86-video-vmware is abandoned and will not work with newer versions of mesa, the default modesetting driver xorg will use should suffice. https://bbs.archlinux.org/viewtopic.php?id=305770 (this doesn't affect the kernel module virtualbox uses for presenting graphics, these are two different pieces of the stack)

If you use Arch in a production work environment and are not staging updates you should probably reconsider your choice of distribution for these usecases.

Generally speaking partial upgrades of any kind are not supported and they will run you into a bunch of trouble: https://wiki.archlinux.org/title/System … nsupported

If you really must operate Arch in such a fashion consider date based snapshots of the complete system state: https://wiki.archlinux.org/title/Arch_Linux_Archive

As for a list of packages installed by a given update, pacman maintains a log under /var/log/pacman.log, for dependency checks/resolution check pactree from pacman-contrib especially with e.g. pactree -r llvm to get all packages that depend on llvm (... a lot...)

Last edited by V1del (2025-06-11 10:21:18)

schnedan · 2025-06-11 11:13:06

V1del wrote:

Drop all IgnorePkg attempts, remove xf86-video-vmware, update your entire system.
xf86-video-vmware is abandoned and will not work with newer versions of mesa, the default modesetting driver xorg will use should suffice. https://bbs.archlinux.org/viewtopic.php?id=305770 (this doesn't affect the kernel module virtualbox uses for presenting graphics, these are two different pieces of the stack)

worth a try...

If you use Arch in a production work environment and are not staging updates you should probably reconsider your choice of distribution for these usecases.

Well no. im my expierience Arch is the distribution with the least problems... still I need to admit: there are more problems in the last 5 years compared with the 10 years before... never the less: its still the one with the least effort and the only one where you can get almost anything from the repros without version issues like Debian. Debian, fedora,... this is hell!

Generally speaking partial upgrades of any kind are not supported and they will run you into a bunch of trouble: https://wiki.archlinux.org/title/System … nsupported

I don't do it by choice... I remember back when I needed to block samba for almost a year or tortoisehg when it wasn't phyton3 ready but arch did a hard cut... no fun for me!

If you really must operate Arch in such a fashion consider date based snapshots of the complete system state: https://wiki.archlinux.org/title/Arch_Linux_Archive
As for a list of packages installed by a given update, pacman maintains a log under /var/log/pacman.log, for dependency checks/resolution check pactree from pacman-contrib especially with e.g. pactree -r llvm to get all packages that depend on llvm (... a lot...)

I know /var/log/pacman.log, pactree,...but thats not what I said. I said: I do not want to parse /var/log/pacman.log by hand or use pactree and then do a X-reference check of dozens of packages by hand. I opted for the tools to be enhanced , so the computer can do the job!

Last edited by schnedan (2025-06-11 11:15:48)

WorMzy · 2025-06-11 11:47:32

Mod note: not an Installation issue, moving to NC.

V1del · 2025-06-11 19:14:24

As mentioned, that Arch tends to do a hard cut with some of these things is somewhat part of the rolling release deal. If you rely on software that's not updated in a timely fashion there are other distributions that can cover this usecase. One can not reliably expand pacman or the existing tooling to "automagically" do this properly. The entire premise of Arch breaks that assumption and the metadata (nor the necessary binary compatibility) to do this correctly is simply not there because it's not what the maintainers envision the distribution to be. If one where to do this, you'd be rebuilding so much of the stack you'd basically create your own distro.

The "debian is hell because of all the different versions" sentiment is precisely contradictory to what Arch does, here you have the other opposite extreme. If software is not compatible with modern libs then the software gets dropped to the AUR, safe for a few exceptions.

schnedan · 2025-06-15 23:55:04

"it's not what the maintainers envision the distribution to be"

Well, I'm now using Arch for more than 15 years and tested all other major distributions,
and while I learned how to manage most problems with Arch, the maintainers and their "envision of the distribution" is what's causing most problems.
Arch is big and for sure the most important next to Debian. It should be about the users and to enable they doing everyday work.

There should be priorities in applications like if samba is broken as it was some years ago, you cant roll on. Same with pyhton3.

I, as others, also made unpleasant contact with "maintainers". if you found some bug and file it accordingly in Arch they just tell a user: its not a arch bug, go file it upstream by yourself.
Me being an engineer and a programmer myself, I can most time deal with it and do it - even if I think, its a maintainers job to coordinate with upstream - not a users task, an ordinary user with little technical background simply CAN not deal with upstream. Say my uncle with his 70+ years. Such people are linux and Arch users too!

Arch maintainers in my opinion need to rethink their roles and responsibilities.
Arch is not a hobbyist distri any more. The rule should be: never break userspace! Things need to work (fortunately they most time do).

Speaking as a software developer, I just don't know any distribution which is stable and delivers most recent compilers and tools. So there is no viable alternate out there. But we all would be better off if Arch maintainers would shift focus on the user and a most stable system for the user. If one of 20 image viewers does not work - nobody cares. If things like samba, python,... have known major problems, just stop rolling until its solved. That would save many individuals many hours of unneeded work.

Allan · 2025-06-16 00:50:03

The maintainers have the privilege of determining the vision of the distribution. If that does not match a users vision then they have two options: (1) become a maintainer and adjust the vision, or (2) go elsewhere.

I'll also note that python2 EOL was January 1st, 2020. Arch removed it almost 3 years later. I find that exceedingly generous.

Arch Linux

#1 2025-06-11 10:09:06

Ingnore Pkg but system gets "currupt" anyway

#2 2025-06-11 10:13:06

Re: Ingnore Pkg but system gets "currupt" anyway

#3 2025-06-11 11:13:06

Re: Ingnore Pkg but system gets "currupt" anyway

#4 2025-06-11 11:47:32

Re: Ingnore Pkg but system gets "currupt" anyway

#5 2025-06-11 19:14:24

Re: Ingnore Pkg but system gets "currupt" anyway

#6 2025-06-15 23:55:04

Re: Ingnore Pkg but system gets "currupt" anyway

#7 2025-06-16 00:50:03

Re: Ingnore Pkg but system gets "currupt" anyway

Board footer