You are right @DanielEckl
In Arch based the system should be updated before any install, (same I learned even in Debian)
But, most likely I won’t be installing software frequently. So, most likely I won’t run into this problem (hopefully). I am just a very normal simple home user, just browsing, reading PDF files, LibreOffice sheets and document, maybe listening to some music.
So, once the software I use is installed it is done. I will rarely need to install new software.
However, as @cscs just got through explaining:
sudo pacman -Syu $package
…which means @DanielEckl, you can install a package while at the same time performing an update.
1 Like
You can also subscribe to notifications for the Announcements category — or any other category on the forum — and then you will see it in your notifications era at the top of the page. 
4 Likes
The infamous GRUB affected most users on Arch and Arch-based users, except Manjaro stable branch, and put and end to comments that Manjaro was more likely to break because packages were held back.
And Manjaro team also created package install-grub to ensure GRUB is correctly rebuilt after an update.
That is not correct. AUR support is disabled by default in pamac-manager GUI and users also have to turn on option to update AUR at the same time as repository packages
pamac CLI has --no-aur and --aur options to exclude or include AUR packages
2 Likes
You absolutely can install without updating, and I almost always do so. As long as what you’re installing is compatible with what’s already installed. pacman was designed to partially ensure this.
sudo pacman -S package
Will only install something if it hasn’t been updated since you last updated your local package database.
It first checks the local database, if the package doesn’t exist in the database you’ll get a target not found error. If it does exist then pacman requests the filename from the mirror.
The filename contains the version, so if the version has changed then you’ll get a 404 error (file not found) likewise if it’s been removed or the name changed.
However if you update the local database using, for instance, -Sy then you may end up installing a newer version which is not compatible with what’s installed.
That’s a partial update, and can cause all kinds of problems - or none, it depends - which are difficult to diagnose and easy to fix, just update.
The same thing happens when you have a failed update, the local database was updated but the system was not. So if you then install something, it may or may not be a newer version which may or may not cause issues.
People like to tell you to always update when installing to prevent accidental partial updates, and the subsequent wasting of peoples time when asking for help. Also to help keep the system up-to-date.
I’ve partially updated 100’s of times, and only a few caused issues, those issues were solved by updating. However I (mostly) know what I’m doing, and always update properly at the earliest convenient time. I wouldn’t ask for help without updating first unless I knew I wasn’t in a partial update state (even then I’d probably update first).
As for the original topic, Updates should be performed at the admins convenience, when they have time to read the announcements and to fix any issues etc…
Updating once every month or two is fine and tends to lead to a nice stable system. There may be exceptions to this but it’s a good rule I’ve used for ~10 years on both Arch and Manjaro, and I rarely have any issues. In fact I’ve definitely avoided a few issues because of this.
3 Likes
My first memory was walking into a room with a line of computers, to learn ‘word processing’.
You see a blinking cursor, you type ‘wordstar’ or ‘wordperfect’ and your word processor opens up in text mode… so for a basic user in some ways it’s simpler - but a more complicated system makes it simpler for most users to just get on and use the damn thing.
You know, like managing a database for a carpet factory…
Haha that’s funny.
It didn’t put an end to it, but then the comments (via reddit and youtube especially) were never based on much more than rumours based loosely on a few personal experiences.
I remember quite a few times that issues came up in Endeavour and Arch which we were ready for… but I also see very frequently (especially on reddit) that many users don’t pay any attention, update blindly, and then complain that Manjaro broke their computer for them.
Obviously, to them, one must simply point out that if they’re too lazy to follow the basic rule of at least checking before running an update, then it’s their fault and they aren’t entitled to a refund under the Manjaro Guarantee.
While I don’t think that Manjaro Stable is more likely to break because packages were held back – my installs have been trouble-free since 2015 and 2016 respectively – I also don’t think that there is more breakage of packages or more difficulty in maintenance when it comes to my Arch/Arch-based installs (Anarchy, Artix, 2 Arch VMs).
They kind of end up having about the same level of problems [ie, practically none] for me. But then I check Arch News, this forum, and carry out maintenance.
I think that is the takeaway here - check forum/distro announcements when you have a distro as actively rolling as Manjaro/Arch-base. Even if Manjaro Stable holds back updates for some time, behind the dam the updates are still piling up. Prevention is better than cure. An old saying but still true.
2 Likes
This is what makes Manjaro amazing.
As I understand, no updates are just pushed out in stable branch before being tested first.
I remember this was the main Grub issue. This is really smart.
In my first thread (sort of, was when I installed), KDE, Stability of Manjaro I have seen many users reporting they have been using the same install for very long time.
Well, I just checked the announcements and found an update and found like 83% of 160 users reporting no issues. So, I considered this safe enough and just ran my script.
One question I have here:
I assume my script checks the time stamp of the update in the repos to decide if 3 days have passed or not to install or not.
This update was just yesterday (first of the month), but when I ran the script, I saw it updating.
Are the updates saved with that date (first of the month, the date the update comes out) or an earlier date when it was moved to stable branch?
Same question another way, I assume for example FireFox was moved to Stable repos mid September, and Libreoffice on the 20th, and the update was “published” or released 1st of October, do they keep those dates or they are all dated 1st of October?
I don’t know how your script checks for updates, but I would suggest scraping it from the forum if you have to. Or provide the RSS feeed that it can test for once a day.
I think your trouble is because of a creation/modification date/time issue. Because the update could have been released yesterday but for some reason or the other it hasn’t propagated to all the servers yet.
I am not having any trouble.
Everything is fine. I reported at announcements that it went fine.
My question is:
My reason(ing) is the same. I didn’t mean troubles with the update, I was referring to your “troubles” with the script.
I have no troubles with the script. It just worked as expected.
The only thing I want to know is about the time stamps of the updates in the repos. Is it when it was moved to the repo or when published and made public?
That’s what I was talking about.
Having the script monitor the RSS feed for the updates once a day, whenever suits you best. Get the date in the title of the latest post and compare it with today’s date. If more or equal to 3 days, go ahead and update. If not, chill.
Because, IMHO I think that looking at the files’ different timestamps might be a Bad Idea TM. I might be wrong, but 
this is my opinion.
3 Likes
Well,
To see the repos and time stamps I did:
sudo pacman-mirrors --fasttrack then checked https://mirror.aarnet.edu.au/pub/manjaro/stable/core/x86_64/
I found folders dated 1/10/2024 (d/m/yyyy) and inside the folder different files with different time stamps.
Now I got the answer to my question.
So, I can conclude, seeing almost all files dated way back much much more than 3 days. So, my script I was thinking of is not really doing much (unless a package just moved to stable just one day before 1/10/2024)
I saw:
| [ICO] | Name | Last modified | Size |
|---|---|---|---|
| [PARENTDIR] | Parent Directory | - | |
| core.files.tar.gz | 2024-10-01 06:56 | 2.4M | |
| core.files | 2024-10-01 06:56 | 2.4M | |
| core.db.tar.gz | 2024-10-01 06:56 | 139K | |
| core.db | 2024-10-01 06:56 | 139K | |
| manjaro-release-24.1.0-1-any.pkg.tar.zst.sig | 2024-10-01 06:25 | 329 | |
| manjaro-release-24.1.0-1-any.pkg.tar.zst | 2024-10-01 06:25 | 14K | |
| linux610-headers-6.10.11-2-x86_64.pkg.tar.zst.sig | 2024-09-26 04:22 | 438 | |
| linux610-headers-6.10.11-2-x86_64.pkg.tar.zst | 2024-09-26 04:22 | 33M | |
| linux610-6.10.11-2-x86_64.pkg.tar.zst.sig | 2024-09-26 04:22 | 438 | |
| linux610-6.10.11-2-x86_64.pkg.tar.zst | 2024-09-26 04:22 | 137M | |
| linux611-headers-6.11.0-6-x86_64.pkg.tar.zst.sig | 2024-09-25 12:32 | 438 | |
| linux611-headers-6.11.0-6-x86_64.pkg.tar.zst | 2024-09-25 12:32 | 34M | |
| linux611-6.11.0-6-x86_64.pkg.tar.zst.sig | 2024-09-25 12:32 | 438 |
So, I assume my script will ignore the first few files as they are dated 1st of October.
I will then have to admit, my script may cause partial upgrades by ignoring some files and installing others.
I will then modify to check the folder date not the file dates and delay for 3 days.
1 Like
I can honestly not comment on how accurate that is.
I do it manually. I check the Stable Updates thread for the latest thread, along with the matray app and an RSS feed so that I’m sure I don’t miss anything, and do the update at a time that I know works for me.
3 Likes
If you want a script then check for new stable update announcements (using RSS), and pop up a notification after a week or two, then check the announcements and update manually at a convenient time. The pop up can contain a link to the specific update announcement if you want.
Or forget the script, just check the update announcements and update at a convenient time.
1 Like
Well, from the discussion here I learned a lot.
I have to admit I reverted back to normal standard update and maintenance, so I updated the script. No timestamp testing.
This is much safer and more efficient.
Thank you all for all your inputs and feed back.
I am learning a lot.
Thank you for the wonderful Manjaro.
Thank you for the wonderful community.
Thank you all.
4 Likes
That is the usual pattern - new user updates for a few months with no problems, but when an update fails they come to the forum to find out why
For every new user that signs up to complain about updates there may be many more users who read update announcements and resolve issues without signing up to the forum
3 Likes
1. User has an issue with Manjaro.
2. User has no clue what the problem is or how to fix it.
3. User creates a Manjaro forum account with the intention of having a bitter rant, while expecting others to magically fix the issue.
4. User is given the solution by well meaning forum members.
5. User fails to comprehend the proposed solution and has a tantrum has another rant.
6. User blames Manjaro for all the injustices in the world and subsequently distro-hops to another Linux.
7. Exchange “Manjaro” with any other Linux; rinse; repeat.
Doesn’t the pattern more closely resemble this?