Sorry Davide but I cannot be totally agree with you.
The updates are manually because aren’t made automatically by the system but not selectable.
You cannot select which updates to be made or not. You can do all or nothing. At least from UI - Software center. Of course you can make updates one by one from CLI but …
So, can we review this (or even the entire topic)?
How to effectively communicate NethServer packages update?
Gabriel
In the next version of Software center, I could allow selecting a list of packages that will be excluded from the next YUM update transaction… What do you think?
Let me see if I understand well:
In Software center will be a list with available updates.
The list will be with check boxes for each available update.
We will select from this list, by checking the boxes, which updates not to be made.
Then we will press the “Update” button and the unselected updates will be made.
The selected updates will not be available next time.
Am I right?
What about this:
In Software center will be a list with available updates.
The list will be with check boxes for each available update.
We will select from this list, by checking the boxes, which updates will be made.
Then we will press the “Update” button and the selected updates will be made.
The unselected updates will be available next time (in the meantime we can find more about them and we can make the updates).
If this will be an opt-out checkbox, then I hope the selection for any future updates will be remembered. If a certain update is not to be executed, then a week or month later it probably isn’t to be executed either unless it has been tested and confirmed not breaking the system.
Usually the check boxes are to select something that we want, like in Software center -> Available.
I don’t want to impose my point of view or to pretend that I’m right but I think that in the same system, the same “symbol” with opposite meaning can induce confusion.
(In the same main place, the Software center, we will make the same operation and we will obtain opposite results, by pressing two different buttons, ADD & INSTALL UPDATES, but having similar meaning.)
Tottaly agree
It is most common and easy to select what we know and we are interested in, instead of selecting that which we do not know.
Zentyal was all or what you want, it was a pain because the packages were listed out of order, but it seems that’s better than selecting to withhold, otherwise you’re stuck with a lot of typing at the cli.
I think cherry picking updates in Software Center is a bad bad thing.
To be able to cherry pick updates, you need a deep understanding of rpm packages interactions and system libraries.
Often, when a CVE is discovered and fixed, upstream releases a bunch of updates which should be installed all together even if there aren’t RPM dependencies between them.
If you really need to cherry pick updates, you must be expert enough to use the shell. Maybe I’m a bit harsh, but if the user doesn’t know how to use the shell, he/she isn’t skilled enough to know what updates need to be installed. 
I would even push the discussion further: why do not remove even the “Remove” button from the Software Center? We had faced many many times problems with users who uninstall packages (and dependencies), and the admin must spend much time to fix a broken system. 
users === admins, I suppose 
admin === support (???)
I agree with you: what we’re talking about is a feature for skilled people. But it could allow people who don’t know how to use the shell to apply updates in situations like Badlock…
The main reason for such a thing would be that a certain update breaks a server or service. In such a case that update should not be released. Can’t there be a mechanism that tests updates before they are released?
We already do it for NS packages and CentOS (and RedHat before it) does tests before releasing.
But as we saw for Badlock bug, it’s almost impossible to test everything even for big companies 
In a government department where I worked we had 140+ servers running. A few servers with minor services running were used as test servers when MS had there monthly 'patch tuesday’
Fridays after ‘patch tuesday’ we updated those test servers. Prior of the applying the patches, we took the server down and broke raid1. After restarting with failed raid1, we applied the patches.
We used to let them run for a week. The next Friday, if we didn’t encounter any issues, the raid1 was recreated by putting back the 2nd disk.
If the patch failed we could bring up the server with the ‘old’ disk and recreate the raid by adding the ‘patched’ disk. The patched disk would be overwritten with the data of the active original disk.
If all went ok all other servers were patched.
But still we had a few servers that ran a certain ancient version of MSSQL and couldn’t be patched since it would break the application running on that database. (those servers weren’t connected to the internet and had their own subnet so the risk of not updating was not too big)
Anyway, long story short: if you update a server, you have to know if you can safely update it. If not, you must be sure you can revert to a previous state.
Nowadays you simply would take a snapshot, but the system (and reason behind it) is more or less the same: be sure that you can revert to a previous state if you don’t know if a patch will work out ok.
Now that @stephdl started to develop a yum-cron configuration package, I’d like to bump also this topic, in the hope of including this feature in the next ISO release.
I’d like to add a new checkbox/action to the items under “Software Center > Installed” tab.
…something like the Android one (did you ever see it?)
Such feature would have been useful, for instance, during the past release of Nextcloud 11, to exclude an installed module from automatic updates. We have to find a way to stop updating (some) module dependencies, though.
That’s different than how I would be inclined to do it.
But then, I’m used to the way that Zentyal, Webmin or even Software Updater in the Ubuntu gui allow selecting any or all pkgs for updates.
Current example… there is an an issue with the Unifi pkgs and the latest kernel on Debian/Ubuntu, with webmin, I can update glibc and vlan, etc, etc and hold back the kernel in the gui so I don’t have to drop to the cli, dependencies are still forced though.
In this way are the shots, my broth!!!
