You are not logged in.
Pages: 1
Topic closed
If I'm correct, there is no option in pacman to perform a "delayed" upgrading, or at least I don't find a way. There are some machines where reliability is the prime factor, and frecuently after a upgrade a few packages become broken. I remember for example a recent apache upgrade (POST request failed due to package compilation problem). Usually these severe problems are corrected a day or two later, since after upgrading many users report and help to fix them. For example, today gcc has been updated again thus I suspect that the previous update (just from yesterday) was buggy.
The idea would be a option to upgrade only packages not updated since X days ago, which are likely to be fairly stable. Currently it is possible to use --downloadonly and then manually perform the upgrade a few days later with packages which aren't too new in /var/cache/pacman/pkg (e.g. 7 or 15 days old). But this is a manual task (and sometimes would cause downloading packages which won't be installed).
For home personal use, a configuration option to schedule update delays for concrete packages would also be useful. For example, if I have not detected problems using the current LibreOffice or Virtualbox versions, I personally don't want to update them and download again hundred of megabytes each time they change the version by just 0.01
Offline
Look into pacman.conf. Specifically IgnorePkg and IgnoreGroup
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
If you're content with using packages at least a week old, you can use ARM, like this: http://arm.konnichi.com/2011/06/22/
Offline
I forgot to mention that in this feature, security-only updates should of course be tag in some way in order to override any upgrade delay.
Offline
I forgot to mention that in this feature, security-only updates should of course be tag in some way in order to override any upgrade delay.
I don't think we have such a feature so you're on your own.
Offline
If you're content with using packages at least a week old, you can use ARM, like this: http://arm.konnichi.com/2011/06/22/
These packages seem to be exactly 7 days old (at least the community repository). I don't mean "upgrade to packages X days old"... what I really mean is "upgrade to packages X days old _if no more recent package is available_" (that is, if such a package has not been "corrected" by any other immediate update).
Last edited by cgarcia (2011-06-29 19:41:03)
Offline
Feature requests should be posted in the bugtracker, preferably with a patch attached.
IMO Arch should not be used for "machines where reliability is the prime factor". There are more suitable distros for such situations.
Offline
IMO Arch should not be used for "machines where reliability is the prime factor". There are more suitable distros for such situations.
Agreed. This is not a package manager issue but a choice of distro issue.
Offline
tomk wrote:IMO Arch should not be used for "machines where reliability is the prime factor". There are more suitable distros for such situations.
Agreed. This is not a package manager issue but a choice of distro issue.
I know that this is a 10 years old thread but it shows up as the first one when doing a Google search.
I am new to Arch having started with Linux in 1994 and I find it an excellent distro with truly extraordinary documentation. A year in, I do not see stability issues either.
The feature to install updates after a cooldown of X days would make it ideal and I will go on looking for a solution before writing my own but I wanted to highlight just another usage scenario similar to OP.
Offline
That's plain not going to generally happen, the best thing you can do if you really feel you need to do this is hook a permanent ALA link: https://wiki.archlinux.org/title/Arch_L … cific_date
I know it sounds good in theory, but the practice of the matter is that you just hit all updates and all the fixes with a X day delay (see Manjaro). The easiest way to ensure this is to just reign yourself in and just update on your own schedule when you have time to look at potential issues.
Cherry-picking "safe packages" is an easy way to shoot yourself in the foot if you're not sure about what you are doing and explicitly something the distribution you are using does not encourage.
Closing this old thread.
Offline
Pages: 1
Topic closed