You could use any number higher than 10. 11 or 99.
The higher the number, the later it is loaded, and therefor the more āfinalā the setting.
If you want to make sure something is applied ā¦ you use 99-something.conf.
But in your example ā¦ 9 would come after 10. Which is one reason why we would follow the nomenclature to include the prefacing 0 if we had some reason to want 09 (as in less than 10).
Huh? You should not edit the system file at /usr/lib.
If you mean you want to augment the new options using a config at /etc/systctl.d ā¦ then as above use 11+ .
And the extra terms can be anything. 99-custom.conf, for example.
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: