Talk:System maintenance

Out of Date Packages

I think it would be a good idea to add a paragraph about out-of-date package, what causes them and how to determine if and which action to take. Mausy5043 (talk) 07:11, 18 May 2020 (UTC)

The procedure is usually as follows:

1. Flag it as out of date on archweb.
2. Be patient and wait. If you can not wait, build it yourself.
3. 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)

This is definitely more "Contributing to Arch" than "System maintenance". Maybe add it to Getting involved#Packaging? -- Lahwaacz (talk) 18:43, 13 March 2021 (UTC)

Partial upgrades

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)

I have a more spelled-out proposal, thought to replace both the first and second paragraphs. See #Draft (Kynikos). — Kynikos (talk) 08:45, 24 October 2015 (UTC)

Regarding the recent moves and merges, I'm wondering what is the current big plan -- is "Recommended package management practices" going to be a separate page or just a subsection of System maintenance? -- Lahwaacz (talk) 10:21, 24 October 2015 (UTC)

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)

I do think we should be careful when extending General recommendations. It should keep as a collection of other pages. And the name Package management is too general and include many different things. --Fengchao (talk) 05:37, 18 March 2016 (UTC)

Draft (Kynikos)

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 IgnorePkg and IgnoreGroup options.

If the system has locally installed packages (such as AUR packages), users will need to rebuild them manually when their dependencies receive a soname bump.

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.

CodingKoopa (talk) 03:20, 23 January 2021 (UTC)

Randomly checking smartctl is 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 is already a section on logging, so we could add a general section for monitoring. Can you draft something? — Lahwaacz (talk) 14:59, 28 August 2023 (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?

Pound Hash (talk) 19:46, 22 December 2021 (UTC)

journalctl will not look in /var/log/, these files need to be examined manually (e.g. with grep). — Lahwaacz (talk) 15:10, 28 August 2023 (UTC)

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.

Pound Hash (talk) 21:00, 22 December 2021 (UTC)

Shall we document Circular Dependency?

Today when I installed ruby I met a warning about Wikipedia:Circular dependency. After some research, I concluded that this package won’t be garbage-collected even if it is marked as --asdeps. This is not too bad, but I think it’s worth being documented?--Franklin Yu (talk) 02:07, 1 January 2023 (UTC)

Why here? There is at least Pacman/Tips and tricks#Detecting more unneeded packages. — Lahwaacz (talk) 08:17, 1 January 2023 (UTC)

I see, I only searched “circular dependency”, so I missed that. I’ll add that to the section you mentioned. --Franklin Yu (talk) 04:44, 18 January 2023 (UTC)

Is there any way to deduplicate the warnings for dependency cycles? Today when I upgrade I saw warnings about ruby-erb twice, ruby-bundledgems five times, and ruby-stdlib 38 times. In fact each of them only need to warn me once, since the messages are exact duplicates. --Franklin Yu (talk)

Maybe ask the pacman developers? — Lahwaacz (talk) 20:13, 29 January 2023 (UTC)