My previous personal experience:
About a year ago I broke my OS by making it un-bootable by installing partial python packages updates (all that server provides at that time). I did not read the unstable thread first. It took me pure several hours to fix it but during some long period of time.
The problem:
a) Frequent (1-2 times a day) updates (as unstable branch usually provides) are not highly compatible with constant daily reading of the unstable thread prior each update to make.
Having updates 1-2 times a day it is unreal to check unstable thread first each time prior an update just in order to read predictable/awaited breaks of the OS, which could be prevented by improving maintenance of the unstable update method.
b) Moreover, updates by portions could lead to problems a days after it fixed by package maintainers: there are may be a servers which got only half of packages rebuilds and then they could break self-sync for a 1-2 of more days and nevertheless a user see a maintainer’s post that it is alright to update now, user still don’t know are their server(s) are synced fully with all portions of python packages or not.
All two items are problems.
Possible solution:
Instead of pushing python-rebuild packages partially into end-user branch (unstable) may be better to create a temp internal branch (for example pre-unstable or any other) and to push any package portion count, any number of days it takes to prepare major part of python packages need to be rebuilt, and only then it is ready - to merge/push bunch of all major packages of that temp branch into the end-user unstable branch.
That solution covers problems (a) and (b). But may be there are more suitable/comfortable solutions for maintainers.
I can’t see an option to start a poll to realize am I alone who lacks the single time push of all major python packages rebuilt into unstable branch or not.
I suggest to
{vote for some intermediate stuff and only if it is ready to push that package bunch into unstable}
or
{vote against some intermediate stuff}
by using thumb up/thumb down marks on this message.
Thank you for taking part in the discussion of that my (as end-user of unstable branch) problem!
All Arch rebuilds were already done and moved from Arch Testing to Arch Stable today mostly all at once. I then synced all of them (almost 3,000 packages) to Manjaro Unstable.
The Manjaro package rebuilds are pushed to the main server as they are built. Some are pushed sooner than others for other packages that require them to build, etc. Then it’s up to the mirrors to sync. It’s up to the user to make sure they are using up to date mirrors.
@alven please use testing branch, as that is aimed for end-users who want to have newer packages. unstable is our staging area and known to be broken. Don’t use unstable on productive machines as it may break by rebuild tasks like python. Only use unstable when you want to support testing the packages and report back missing rebuilds of packages.
sudo pacman -S manjaro-check-repos
Sync unstable after Arch updates to Python 3.12, then see what needs to be rebuilt:
Medmedin, by answering on my suggestion to create an pre-unstable branch for internal usage before to share packages to end users, Philm said that staging role is already taken by unstable branch.
So: unstable is internal staging branch dedicated to experiments by the Manjaro Team, including partial updates.
As noted in the problem description, the partial updates state could reach the unstable not only by pushing each package after it was rebuild is ready (described part (a)), but after sudden pause of self sync of any server sharing branch updates, which could stop/hang in that partial update state for several hours and days (described part (b)).
Based on that, I can conclude, that unstable is internal staging branch of Manjaro Team, which just is shared to any user that want to use that branch dedicated to internal Manjaro Team use and easily could reach and - cause update server does not updates immediately and could hung up - to save the broken state for some period of time.
Moreover, properly/safer usage of the unstable branch is to read the forum’s unstable thread each time prior to update.
Medmedin, as you did, I also previously thought that there 3 waves (branches) of package updates dedicated for end users:
unstable,
testing,
stable.
But after Mark’s and Philip’s posts I concluded that there are only 2 dedicated for end users:
testing,
stable.
And unstable is used as internal staging branch of Manjaro Team, which is free to join by any user, just shared widely but architecturally designed to be dedicated for internal usage of Manjaro Team as staging branch with partial packages updates (as each single package got rebuild and is ready - it immediately pushes into unstable). So server self-sync easily could act inside of that rebuild period and share to end users the partial update state.
But if we talk about prevention of getting partial packages update state (at least after python updates), we should use the testing or stable as having packages update states as settled down / staged / always fully ready to update (all queued packages to rebuild are done and always ready to update) - to have almost all bunch of package rebuilds at once.
That’s how the part (a) and part (b) of my problem getting solved in the Manjaro OS infrastructure.
Thanks, now I got it. Switched to first wave of new packages dedicated for end users (the testing branch).
Depending on which packages you are using.
If you use a lot of installed Manjaro packages and Manjaro Kernel (they are built by Manjaro), you’d better switch to the testing branch.
The output shows which installed packages are built by Manjaro only.
I don’t have many problems with the unstable branch so far, because I use very few Manjaro packages for example: grub, systemd, pacman and mesa … they are built by Manjaro and do not use Python dependencies.
The rest many installed packages (unstable branch) are the same as those from Arch stable branch. They are simply copied 1:1 from Arch mirror to Manjaro unstable branch. They work without any problems in my experience.
In the unstable branch, I am very cautious about Manjaro bleeding edge kernels that have not been tested by Arch team and Manjaro team, but they are tested or used directly by you and Manjaro team first. For this reason, I use my own “stable” Kernels.
Of course, a bad bleeding edge Kernel can destroy your data if a filesystem has new critical bugs and its testing is not enough.
Unstable branch is where everything enters the Manjaro eco-system.
If you are using unstable branch - you are offering yourself as test-rabbit - but you can use it as an ‘end-user’.
If you want to consider yourself as ‘end-user’ - I have said this before - disable update checkers - schedule your updates to e.g. once a week or twice a week - what suits you.
There is only this monthly announcement for packages added or updated in unstable - offering the members to option to report their issues - if one encounter a deal breaker.
As you can see from the discussion - there is a process which will streamline the release cadence with automated releases.
I’ll be starting Python 3.12 rebuilds shortly. I do not recommend updating for few hours.
Everything should be (mostly) done. Let us know if we missed something.
My previous personal experience:
The problem:
