Talk:System maintenance

From ArchWiki
Jump to: navigation, search

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.