Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#1477 - [Patch] UpgradeDelay feature for Pacman

Attached to Project: Pacman
Opened by Indan Zupancic (i3839) - Sunday, 19 September 2004, 15:56 GMT
Last edited by Judd Vinet (judd) - Sunday, 19 September 2004, 17:50 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Judd Vinet (judd)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

For more info see this thread:

http://bbs.archlinux.org/viewtopic.php?t=6885

The patch can be found at:

http://nul.nu/~indan/upgradedelay-2.9.patch

Summary:

When doing `pacman -Su` upgrade only the packages that are at least 'UpgradeDelay' days old. People who want to be bleeding edge simply don't set the option in pacman.conf, others that want more stability set it to a higher value like 14 days. That way if there is a critical bug in a new package and there's a fixed version within those 14 days, the broken version won't be installed (and the fixed one after 14 days if it proves to be "stable").
This task depends upon

Closed by  Judd Vinet (judd)
Sunday, 02 October 2005, 18:41 GMT
Reason for closing:  Won't implement
Comment by Nikos Kouremenos (zeppelin) - Thursday, 14 October 2004, 12:06 GMT
this is a very nice idea because a lot of users are afraia of 'extra bleeding edge'. :)
eventhough now with the testing repo & this patch it will be for really conservative ArchLinux usage [which is not bad again]
Nice!
Comment by Indan Zupancic (i3839) - Thursday, 14 October 2004, 13:37 GMT
To be honest I made it mainly to avoid downloading a lot very short living (thus unstable) packages. How bleeding edge I want to be is more or less proportional to how often I do a system upgrade, so I could add an autotune option which uses an upgradedelay time relative to the time since the last upgrade.

E.g. after two weeks I do a sysupgrade, the upgradedelay time will be autotuned to something like log(time since last update) * some constant.

But I guess I'm the only one that finds that useful, so let's keep focused on the static, user configurable upgradedelay time. :-)
Comment by Indan Zupancic (i3839) - Saturday, 23 October 2004, 14:18 GMT
It would be nice if the gensync patch would be merged, so that I and others can use a patched pacman for the UpgradeDelay feature. The pacman patch on it's own is useless if the package database doesn't preserve the time.

diff -Nurp pacman-2.9/scripts/gensync pacman-2.9-ud/scripts/gensync
--- pacman-2.9/scripts/gensync 2004-09-19 17:16:26.000000000 +0200
+++ pacman-2.9-ud/scripts/gensync 2004-09-19 17:17:20.000000000 +0200
@@ -134,6 +134,8 @@ db_write_entry()
done
echo "" >>depends
fi
+ # preserve the modification time
+ touch -r $1 desc depends
}

if [ $# -lt 2 ]; then
Comment by Judd Vinet (judd) - Monday, 25 October 2004, 17:12 GMT
yep, it's used on dragon now, will be in the next release of pacman.
Comment by Indan Zupancic (i3839) - Monday, 25 October 2004, 21:10 GMT
Thanks.
Comment by arjan timmerman (blaasvis) - Sunday, 02 October 2005, 09:07 GMT
is this taken care of ?
Comment by Indan Zupancic (i3839) - Sunday, 02 October 2005, 10:36 GMT
The gensync patch is merged, and the UpgradeDelay feature isn't in Pacman yet. Perhaps it's time to decide if it is wanted or not, then this matter can be closed. I think it's the closest thing to something like a "stable branch" you can get with a rolling release system without any additional overhead.

Loading...