Out of Date Packages
- The procedure is usually as follows:
- Flag it as out of date on archweb.
- Be patient and wait. If you can not wait, build it yourself.
- If more than three weeks have passed and you want to help updating the package, build the newest version yourself and tell the maintainer if it works or not. Do not forget to be kind and respectful or your mail shall be cast into oblivion.
- I actually asked this one of the developers in the IRC channel and it seems like point 3 is an unwritten rule. Because there were plenty of confusions about that in the past I am in favor of documenting this but I am not sure if this article is the right place for that. Perhaps the Package guidelines page is a better place for this? I am not a developer though.
- -- NetSysFire (talk) 16:29, 13 March 2021 (UTC)
I'm unsure on this sentence in System_maintenance#Partial_upgrades_are_unsupported:
- That means when new library versions are pushed to the repositories, the developers and Trusted Users rebuild all the packages in the repositories that need to be rebuilt against the libraries. Thus if a user selects specific packages for upgrade (rather than upgrading the whole system) they can end up with packages with missing libraries.
I see what you mean, but you could interpretate "packages with missing libraries" as that the contents of the package itself were removed from the package contents, rather than that the package/application searches for a specific library version and that was removed (or replaced with an incompatible version). -- Alad (talk) 17:44, 23 October 2015 (UTC)
- Yeah... I felt the previous description didn't make the problem clear enough, but I didn't want to make the explanation too long. I gave it another go just now. Silverhammermba (talk) 18:44, 23 October 2015 (UTC)
- Here's my attempt:
- Arch Linux is a rolling release distribution. That means when new library versions are pushed to the repositories, the developers and Trusted Users rebuild all the packages in the repositories which depend on those libraries. If only the library is updated - possibly by updating a different package which also depends on it - then the application might break, as it still depends on the older library version.
- I guess it's the same in the other direction, i.e you try to run something that depends on a higher soname (but we're not Debian). Ah, the fun of explaining these things in two sentences. I'm fine with your current wording considering the context, either way. -- Alad (talk) 19:48, 23 October 2015 (UTC)
- Here's my attempt:
- I think it would be ideal if we could keep it here; the contents overlap and the topics are related - e.g it makes sense to have System maintenance#Backup in the same article as System maintenance#Upgrading the system. Of course we can revisit this as the drafts (and current articles) develop. -- Alad (talk) 17:03, 24 October 2015 (UTC)
- Besides System_maintenance#Tips_and_tricks with stability topics, also System_maintenance#Use_the_package_manager_to_install_software does not fit to this page. It is hardly regular system maintenance when you "install new software", "choose open-source drivers" or "[are] careful with unofficial packages". So I would prefer separate page for the "Recommended package management practices", this page could then link only to the relevant section about system upgrades. Since my draft builds mostly on existing content, I'm proposing to move it to the main namespace to solve the organization problems. Since Silverhammermba's draft takes different approach, his changes can be applied later to improve the content. -- Lahwaacz (talk) 17:36, 24 October 2015 (UTC)
- Well, we already have a lot of (loosely coupled) pages which discuss packages, so "unifying" them is a good idea; see Talk:Pacman#New approach. That said, it's true that those topics aren't very fitting with regular maintenance.
- How about using General recommendations/Package management as title, merge General recommendations#Package management there (This would also take care of #Mirrors), and see what remains of this page. Likely the left-overs could be merged to General recommendations or General troubleshooting. -- Alad (talk) 11:09, 25 October 2015 (UTC)
- I agree with merging General recommendations#Package management, System_maintenance#Upgrading_the_system, System_maintenance#Use_the_package_manager_to_install_software, User:Lahwaacz/Recommended package management practices and User:Silverhammermba/Recommended package management practices into General recommendations/Package management, which is a title practically equivalent to "Recommended package management practices", but with the relation with General recommendations made explicit.
- General_recommendations#Package_management can then become a subsection on General_recommendations#System_administration, but I would do more than simply generically link to General recommendations/Package management from there, and specifically link to its most important sections, since it's important to ensure that new users don't overlook it.
- The remainder of this article could be similarly moved to General recommendations/Maintenance, I don't see it fit for General troubleshooting, and it has a different nature from General recommendations after all.
- — Kynikos (talk) 13:38, 25 October 2015 (UTC)
- +1 for the big merge to General recommendations/Package management. Though I'd like to point out that the current content of General recommendations#Package management really isn't general recommendations for package management. It's more like... general information related to package management. I don't think that info needs to be merged. Silverhammermba (talk) 17:59, 26 October 2015 (UTC)
Arch Linux is a rolling release distribution: in general, only the latest version of a package is available in the repositories. When a new library version is pushed to the repositories, all the packages that depend on it are rebuilt and pushed to the repositories as well. This means that synchronizing the pacman database and only upgrading selected packages (known as a partial upgrade) can cause applications to become unstable or completely stop working.
Suppose for example that app-foo depends on lib-bar. If a new version of lib-bar is released upstream, it is pushed to the repositories together with a rebuilt version of app-foo. If now the pacman database is synchronized (
pacman -Sy), and then:
- only lib-bar is updated (
pacman -S lib-bar), app-foo may stop working, since the installed version still thinks that the old lib-bar is installed;
- only app-foo is updated (
pacman -S app-foo), app-foo may stop working, since the new installed version thinks that the new lib-bar is installed.
This is why partial upgrades are not supported and strongly discouraged: never run a similar sequence of commands such as
pacman -Sy app-foo. In general, you never want to use pacman's
-y option without the
-u option, i.e. after synchronizing the pacman database, you always have to upgrade all the installed packages. The supported command sequences to install app-foo are:
pacman -Syu app-foo
pacman -Syu && pacman -S app-foo
pacman -Sy && pacman -Su app-foo
pacman -Sy && pacman -Su && pacman -S app-foo
Note that there are other less evident scenarios that can cause partial upgrades, notably when freezing specific packages with the
Add disk health status
I've had a couple of drives fail suddenly, without realizing that they were in poor health. It would nice to have a suggestion on this page to check the Disk health status.
- Randomly checking
smartctlis a bit tedious, so this should probably go with some monitoring or
smartd. Backups however are already mentioned, so I think it implies this already. This is also more like "physical" maintenance (also applies to every operating system) in my opinion, I do not know if this truly belongs here. -- NetSysFire (talk) 15:39, 22 March 2021 (UTC)
There aren't any instructions on how to check for errors in /var/log
Under the subsection Logfiles under the section Check for errors, it says,
Look for errors in the log files located at /var/log, as well as high priority errors in the systemd journal: # journalctl -p 3 -b
Will journalctl check for errors in /var/log? If not, where do we go to learn how to do that?
There are two distinct sections regarding orphaned packages
I would think principles of efficiency, simplicity, and neatness would oblige us to merge these two sections.
The first instance is under Use the package manager to install software, while the second falls under Clean the filesystem.
rmshit.py removes ~/Desktop and that is dangerous
"To keep the home directory clean from temporary files created at the wrong place, it is a good idea to manage a list of unwanted files and remove them regularly, for example with rmshit.py."
I tested rmshit.py and it suggests and removes the ~/Desktop if you say Y at the prompt to execute it. Python code says "'~/Desktop', # Firefox creates this" but it is not true.
This is a serious situation if you blindly trust the program or if you have a long list of removal suggestions and don't notice that ~/Desktop is there too. Makes no sense to remove the ~/Desktop.
Maybe it should be removed or put a warning.
- The script asks the user if they want to proceed, so you get a warning when you run the script. It might be argued that all files and directories created on your disk have some purpose. So since the script is based on a hardcoded list of files and directories, every single item contained in it might be a false positive. If you don't like the default list, feel free to fork the script and maintain your own list. — Lahwaacz (talk) 18:03, 11 March 2022 (UTC)