Contributed by grey on from the christmas means it's time for new packets dept.
Just wanted to let everyone know that espie@ seems to be working on a package update tool. Someone had mentioned that he was already working on it, but I saw a commit on the 23rd here. that shows his first commit of this code.
A recent poll on obsdj showed that quite a few people were clamoring for more automated update tools, I thought they should know that he was working on it. FYI these are package update tools, not binary patches for the OS.
(Comments are closed)
By Matt Van Mater (68.49.156.213) on
Comments
By grey (64.139.7.172) on
By Michael Knudsen (217.157.199.114) on
By sand (217.220.29.251) sandman@mufhd0.net on
By Anonymous Coward (130.225.60.47) on
By brad (203.122.237.54) on
Comments
By Matt Van Mater (65.205.28.104) on
openbechde web site
Comments
By Marc Espie (62.212.102.210) on
It's called pkg_add -r, for now.
What it does, very simply, is allow one person to replace a package with another one `safely'.
It assumes the new package is going to conflict with the old one, and is using conflict information to figure out which package to kill.
As for safety, pkg_add -r tries to run a large amount of checks before it commits to the update, like checking dependencies first, and extracting all files from the new package before updating.
If you think about it, it is handling pkg updates like a race condition: there is a point where the old package is no longer there and the new package is not yet installed.
If anything fails at that point, you're fucked, so let's try to make the window of vulnerability as small as possible.
As mentionned in all my commit messages, this is completely experimental code for now, and not safe at all for production use.
The point being, this work happens fairly early in the release cycle, so that we developers and beta-testers get a chance to polish it before the next release.
Also note that pkg_add -r is the first stone in the update bridge.
Namely, it's there to show that individual update operations can be made fairly safe. The actual pkg_update tool will happen later, and will do things on a grander scale, like figuring out by itself what to update to what...
but for this to work out, pkg_add -r needs to be perfect, and to be tested.
Simply put, just by having this mechanism available, we're going to figure out a lot of non-trivial consequences of updating operations.
As usual, OpenBSD relies on evolution, not revolution....