Manual intervention is necessary to regain the graphical tools for Firewalld

I don’t use it for exact this reason (well the second reason is it is not eos standard). I was strictly referring to the applet itself.

Thanks @joekamprad :victory_hand:

The “firewall information” page of the Welcome app does not yet reflect this change. Could the article be updated?

Cheers :victory_hand:

Is there anything to update there? The only thing that has changed is how to install it. We will update the installer so it is installed out of the box.

It also looks like the new packages have already been added to that page.

Is there something on that page that is no longer accurate?

That settles it then. :+1:

Very greatful :+1:

According to me it is a miss from the Arch team. This ought to be listed in the news section. Why did this firewalld split actually occur?

changed that already before.. added the info on optional firewall-config package and info on the split packages available:

They could have, but there is no real reason, as of user is getting the info on update, and it is no general manual intervention needed. The firewall itself will still run fine.
Only that the config GUI and the applet and testing tool, is now in seperate packages, so you can install if needed.

The firewall itself is working without them, it has proper cli commandline tools to setup and manage.

I would guess that Arch is going for smaller, more atomic packages so you can install only the parts you want.

Splitting packages into more atomic or smaller packages will increase the work load of the maintainers and owners of the package. I know it aligns with the Unix philosophy of having small programs that do one task exceptionally well and then chain them to achieve an outcome. But in case of firewalld package, the the GUI of firewall package cant be used by any other tool. Only firewalld can use it. The firewalld applet also is in the same bucket. Most of the DE/WM depend on applets from the firewall provider.

If a package gets too big, say in excess of 128 MB or more then yes it should be a candidate for splitting. Other than that justification seems dubious.

It would be so much better if the Linux Kernel, which is a massive monolith, become a more modular entity.

only showing its not really a lot more work:

Split packages are handled in one PKGBUILD

And on the user side pacman will show “optional needed” packages with the info on what are these for.

Not ideal, but thats how arch/pacman handles things.

And you are the owner or maintainer of the package and someone decided to get you more work now? If not, why worry about it.
Installing Arch means to install a system without any graphical user interface. Maybe you have no need for a graphical desktop but want a firewall. From this point of view the split is the only way to work the arch-way. Distros depending on Arch, like EndeavourOS, can change the configuration to make it the best experience for their users.

I always do yay -Pw and also check Software News in Welcome. This particular issue was noted in the latter.

Is firewalld-test needed outside of development?

I couldn’t find anything here: https://firewalld.org/documentation/

@joekamprad is there a reason to not instead run
sudo pacman -S --asdeps firewall-applet
since they are all optional pkgs of firewalld?

No, you don’t need that package.

This is what I did.

Rookie question what does this part do ?

You can use

man pacman
--asdeps
           Install packages non-explicitly; in other words, fake their install reason to be
           installed as a dependency. This is useful for makepkg and other build-from-source tools
           that need to install dependencies before building the package.

And don’t use –asdeps in combination with -Syu !!

see:

good point!