Do not update single packages on Archlinux, but
from thingsiplay@beehaw.org to linux@lemmy.ml on 01 Oct 12:05
https://beehaw.org/post/22451771
from thingsiplay@beehaw.org to linux@lemmy.ml on 01 Oct 12:05
https://beehaw.org/post/22451771
On Archlinux it is not recommended to update only one package with the package manager pacman. Let’s say I have 11 packages, and one of them is extra/firefox (true story). Updating only a pacman -S firefox could introduce problems, but installing a new single package if it wasn’t there is okay.
So my question is, could we get around this by removing and installing the same package again in one go: pacman -Rs firefox && pacman -S firefox
threaded - newest
When installing on Arch (or a derivative) you should run
sudo pacman -Syu package_nameso it is always up to date.it’s just unsupported. like, if something breaks by that happening then it’s not a bug, but your fault.
installing a new package without updating is the same as updating a single package
That is not true. Installing a package with
sudo pacman -S packagewithout updating the package list is totally supported and works without problems. Whats not recommended is to installing package and updating package list with-Sy package. So instead we should do-Syu packageand update everything on the system alongside the package.Maybe if the package list is old, then
-S packageit will only install from cache? Could it be that?Yes,
pacman -S packagewill install the version of the package that is listed in the current package database, and will not do anything to update that database.Not true. It says clearly “Partial upgrades are not supported”. Whether the package was there or not is irrelevant. And I really don’t mean this personally, but as general advice, using Archlinux and its wiki requires a modicum of independent thinking.
edit: clarification:
It is OK to use ‘-S’ only if all installed packages are on the same level as the local package info. That is assuming that the cached local version of the package is still available on package servers.
Also read wiki.archlinux.org/title/System_maintenance#Parti…
But
-S packageis not upgrading thepackage(Edit: I meant system). Installing with that command is supported. That is NOT a partial upgrade of the system.-Sy packageis considered a partial upgrade, because that command updates the package list.This part was a total unnecessary attack, for someone who asks. Especially if you are not entirely correct.
It is OK to use ‘-S’ only if all installed packages are on the same level as the local package info. That is assuming that the cached local version of the package is still available on package servers.
I just think you’re being too literal about this, instead of thinking about the reasoning behind that rule.
I disagree. The
-Sflag stands for “sync”, which means sync the local version with the remote version. So if there is no local version it just installs the remote version. This is still a partial update, because any dependencies it might have, that you already have installed, might be the wrong version compared to the one the newly installed package expects.pacman -Sshould be discouraged because of this. The correct one ispacman -Syufor installing new packages.No,
pacman -S packageis safe. Because the package list is not updated this way, and therefore the system is not updated and nothing else is affected. New packages can be installed with this command, perfectly okay. That is in the spirit of Archlinux.I think my idea would not work because the nature of the command
-S package, as no new version would be synced. This is not a partial upgrade and it does not need to be discouraged.If the package is not in your cache, it needs to download it from the remote server first. The version on the remote server is built against the dependencies on the remote server. So if your local dependency is older, it will be a partial update!
No, because
pacman -Swill use the current package list.And where does it download the newly installed package from? It’s not in your cache, because you haven’t had it installed before and the remote server only has the newest version.
I guess that’s the key takeaway for me from this post and replies.
The download will simply fail if the version pacman wants to download isn’t available on the mirror. The version is part of the download URL.
If you have not ran a database update (any y after -Sy), pacman will fetch the version that is compatible with your _ current_ installed dependencies.
The remote server only has the latest version of the package, and the latest version is always built against the dependencies on the remote server. So if you didn’t update the database, then your pacman -S command will fail, because it can’t find the package version on the remote server. So you did not install anything.
You’re correct partial upgrades are unsupported. Arch follows a rolling release model, meaning there are no fixed “versions” of the system. Instead, everything is continuously updated. Each package is built and tested against the current state of the rest of the system in the Arch repositories. That package was compiled against the latest system libraries in the repos, not necessarily the ones on your machine.
Your proposed “workaround” may work if the package is standalone and has few/no dependencies. Again, ArchLinux strongly recommends full system upgrades (pacman -Syu) rather than only reinstalling/upgrading a single package, because library or dependency mismatches can occur if your system is out of sync.
A safer approach may be to use “pacman -S package --needed” which will avoid removing it first and automatically handles dependencies safely.
But
pacman -S packageto install a new application is not considered a partial upgrade.I feel like there is an underlying issue here you’re trying work around. Why do you not want to update everything together?
I think you are a little confused at the problem here. The issue is that partial updates are not supported. The reason for this is very simple, Arch ensures that any given package list works on its own, but not that packages from different versions of the package list work together. So if Firefox depends on libssl the new Firefox package may depend on a new libssl function. If you install that version of Firefox without updating libssl it will cause problems.
There is no way around this limitation. If you install that new Firefox without he new libssl you will have problems. No matter how you try to rules lawyer it. Now 99% of the time this works. Typically packages don’t depend on new library functions right away. But sometimes they do, and that is why as a rule this is unsupported. You are welcome to try it, but if it breaks don’t complain to the devs, they never promised it would work. But this isn’t some policy where you can find a loophole. It is a technical limitation. If you manage to find a loophole people aren’t going to say “oh, that should work, let’s fix it” it will break and you will be on your own to fix it.
Focusing on your commands. The thing is that
pacman -S firefoxis always fine on its own. If Firefox is already installed it will do nothing, if it isn’t it will install the version from the current package list. Both of those operations are supported. Alsopacman -Rs firefox && pacman -S firefoxis really no different than justpacman -S firefox(other than potentially causing problems if the package can’t be allowed to be removed due to dependencies). So your command isn’t accomplishing anything even if it did somehow magically work around the rules.What is really the problem is
pacman -Sy. This command updates the package list without actually updating any packages. This will enter you system into a precarious state where any new package installed or updated (example ourpacman -S firefoxcommand form earlier) will be a version that is mismatched with the rest of your system. This is unsupported and will occasionally cause problems. Generally speaking you shouldn’t runpacman -Sy, any time you are using-Syyou should also be passing-u. This ensures that the package list and your installed packages are updated together.But I’m not doing
pacman -Sy package. That is not what I am talking about. I am only talking aboutpacman -S package, which is not updating the system partially. IF the package depends on something else to update, then the system would need to be updated. But that is not what I was asking, because I only talk about the package with-S package. I just chosefirefoxas an example, it could have been any other package.To make it clear, when I say
-S firefox, then I mean really that without updating a dependency like libssl. The idea is to install only new packages without updating anything on the system. I guess as you say it depends on the dependencies of the package, if this is feasible.But that is my point. Just running
pacman -S firefoxis fine as long as you didn’t runpacman -Syat some point earlier. It won’t update anything, even dependencies. It will just install the version that matches your current package list and system including the right version of any dependencies if they aren’t already installed.But that means if you already have Firefox installed it will do nothing.
We can install a new package if it wasn’t installed with
pacman -S firefox. That is not a partial upgrade of the system. Right? What i don’t understand is, when I uninstall withpacman -Rs firefox, delete the cached firefox package (only that file), then the system is in the same state as before I installed it. Then-S firefoxshould be okay, right? And it even looks up the new version. This is my question, if that would work correctly.IF no dependency tries to update too. Off course in that case I would stop. Without
pacman -Sy, I never do that anyway, only-Syu.That’s all you need to know. As long as you always use
pacman -Syuyou will be fine.pacman -Syis the real problem. The wiki page is pretty clear about the sequences of commands that are problematic wiki.archlinux.org/title/System_maintenance#Parti….This isn’t correct. It won’t look up the new version. Assuming that the system was in a consistent state it will download the exact same package that you deleted. The system only ever “updates” when you run
pacman -Sy. Until you use-yall packages are effectively pinned at a specific version. If the version that gets installed is different than the one you removed it probably means that you were breaking the partial update rule previously..
To add to the other comment, package managers keep a local copy of the list of available packages and the version. When you do a
pacman -S xxxthe package manager looks up xxx in the cache and downloads the package from whatever mirror youre using as well as any dependencies, looking them up in the same way from your cache. This works for a while even if theres a new update available because mirrors usually keep a few previous versions.Once you do a
pacman -Syyou update your cache to the latest one. If you then update xxx, it will update xxx and pull in any dependency updates required, but any other packages that depended on the same packages dont get updated, leaving you in a partially upgraded state.I’m not familiar with arch or pacman. What prevents a package from becoming too new? Like if a new version of libssl is released that removes a necessary function but a package like Firefox has become abandoned, then even updating everything will result in a broken application. Does it not have version dependencies like debs and rpms?
I’m also not familiar. But my understanding is that the package maintainers should prevent this situation. Because otherwise even if there are package version dependencies (I don’t actually know if pacman does this) it would just block the update which results in a partial update which isn’t supported. For example if your theoretical unmaintained Firefox blocks the update of libssl but Python requires new functionality you would be stuck in dependency hell. Leaving this problem to the users just makes this problem worse. So the package maintainers need to sort something out.
It is a huge pain when it happens but tends to be pretty rare in practice. Typically they can just wait for software to update or ship a small patch to fix it. But in the worst case you need to maintain two versions of the common dependency. In lots of distros very common dependencies tend to get different packages for different major version for this reason. For example libfoo1 and libfoo2. Then there can be a period where both are supported while packages slowly move from one to the other.
If a package manager can block an upgrade due to version dependencies, it can also pull in those dependencies for a partial upgrade.
If a function is removed from libssl and it’s used in firefox, firefox build would fail, so it’s still not possible to have a functional setup.
Yeah, that kind of a condition would require the maintainer to patch the source of the non-updated program.
And that would be fine if there is just a little change, with an alternate function available but if the change requires changing the logic of the application, you are essentially expecting the package maintainer to do the software developer’s work.
The deprecation process is a good way to prevent this.
Adding on to what the other commenter mentioned, that is called a breaking change and would generally be avoided at all costs by libssl. See, e.g., the decades-long python3 transition.
This is an excellent answer and I wish I knew all of this when starting to use archlinux. “Arch does not support partial upgrades” is something you can read everywhere, but it’s rare to find such a good explanation of what exactly a partial upgrade is, and which commands lead to it.
I only learned about all of this when I got into some broken state by randomly running pacman commands.
Everyone, be like this guy. This guy explains stuff well. Newbies need stuff explained.
It is only a partial upgrade if you update your databases, without upgrading the rest of your system. If you try to
pacman -S firefox, and it gives you a 404, you have to both update your pacman databases, and upgrade your packages. This will only give you a 404 if you cleaned your package cache, and your package is out of date. Usually,-Son an already installed package will reinstall it from cache. This does not cause a partial upgrade.If you run
pacman -Sy, everything you install is now considered a partial upgrade, and will break if you don’t know exactly what you’re doing. In order to avoid a partial upgrade, you should never update databases (-Sy) without upgrading packages (-Su). This is usually combined inpacman -Syu.This thread managed to make my head spin. Why do you make it so complicated to update packages. Are you from Microsoft? :)
I don’t know what you mean, the question is simple.
Your comment is a good example of waste of bytes, unhelpful and rude
No,
pacman -S firefoxwill not update your firefox.pacman -Sy firefoxwill update your firefox and nothing else.If you have done
pacman -Syonce, then your list of packages and their versions gets updated.From then on, using
pacman -S <package>on any package, whether or not it was already installed, will now get the new version of it.On the other hand, if you have not updated for long, then if you run
pacman -Suto update, it will update nothing, because it looks at the old package list and compares it to installed packages and all of them match.If you were to use
pacman -Syand thenpacman -Su, then it would do the update, similar topacman -Syu.If you did
pacman -Syyesterday and then dopacman -Sutoday, then it will update up to yesterday’s packages and will ignore any updates from that point to today.This can be considered analogous to
apt updateandapt upgrade.If you run
apt upgradewithoutapt update, you only upgrade upto the packages that you got until the lastapt update.If arch used
apt, then in this case, the recommendation would be for never useapt updatewithout usingapt upgraderight after it.Isn’t
pacman -Syuthe recommended way to update anyway? I have always used that o. EndeavourOS and hadn’t any issues.Except for the recent nouveau nvidia driver :/
Yes, but it is also good to know why it is recommended.
I haven’t used Arch in a decade, but as unstable as Arch is, I don’t think Arch doesn’t have dependencies poorly defined like that.
Say, firefox-1 does not depend on libssl-1, but now you upgrade it to firefox-2, you won’t succeed if you successfully downloaded firefox-2, but failed to download libssl-1, because pacman shall fail, while saying the reason being failed to download all of its dependencies.
If you start with a system with both firefox-1 and libssl-1 installed, upgrading firefox-1 to firefox-2 sure would have no problem, because its dependencies are already fulfilled.
If your system is breaking, it’s probably due to some other issue, but it could not be pacman’s.
It seems like there might be exceptions to the “no partial upgrades” which has not been discussed: you can pin your version of the kernel primarily to give time for packages like zfs to catch up to the latest kernel
What part do you mean is the exception? Pinning a package version will lead to partial upgrades, by logic. So pinning the Kernel isn’t an exception itself, maybe its tolerable because the team tries to make sure this scenario works well? Otherwise I wouldn’t call it “exception”.