You are not logged in.
I am not sure if its already in plan if an upgrade of a package doesn't work user can reinstall the old package back. A similar idea (package rollback in pacman) was suggested one year ago in topic: "What will Arch Linux 1.0 become?". But that's when a package fails to upgrade.
http://bbs.archlinux.org/viewtopic.php?t=336
This would require to store the last workable packages in separate repo (backup). To install a backup file e.g. "pacman -Sb <package>" (removes existing package and installs the backup file).
In general, a user don't mind too much if an upgrade package doesn't work but gets annoyed when the previous pkg is no longer available. With this type of backup system the package maintainers get more time to fix the errors.
EDIT:
If not as a pacman option but at least one backup repo.
Markku
Offline
I agree with your idea ....
Maybe not part of pacman but a new wrapper that could remove lastest version of a package...& reinstall previous one in one hit....
pacnuke <package>
Mr Green
Mr Green
Offline
personally i don't like the idea of a roll back option. i am more an advocate for making sure, to the best of one's ability, that highly interrelated packages be as thoroughly tested as possible. i know some devs would then say well we need another computer to do so.... well if that is what it takes then perhaps it should happen. i know that may seem callous since none of them get paid for their services but perhaps what funds that are coming in could go to getting some more test computers? retro fitting a rollback option into pacman is likely doable but just the whole adminitration of it is an annoyance (maintaining two three more repos or at least one big one), it divides resources (developers have to maintain two version of everything), and rolling back in a integrated package set could be disasterous (i remember how bloody hard fixing kde or gnome problems in debian was and in that distro you can rollback to some degree).
jsut some thoughts.
AKA uknowme
I am not your friend
Offline
Another Computer or another user test it on the one instead of infecting the many....
I am quite prepared to help cmf if he needs someone to test KDE packages for example....
And I am sure others would do the same.....
Mr Green
Mr Green
Offline
I'm with Sarah on this one (therefore trouble is brewing). Arch is meant to be kept up to date. There have been problems with packages that testing isn't catching, but I don't think this is the correct fix. Somehow, the packages should be fixed before they are released, or maybe the users could be a little more patient when there is a problem. They could even go to the trouble of submitting a patch...
Dusty
Offline
There's a lot less involved, technology wise, than what Sarah is thinking. I've spoken to Judd about adding rollback to pacman. Hell, it might just end up being a wrapper...
It will be a feature that's available sometime. Check out how rpm does rollbacks (linuxjournal had an article about it recently), it'd be similar, logic-wise, to that.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
So this will mean we'll use twice as much server space?
If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. 1 Corinthians 13:2
Offline
So this will mean we'll use twice as much server space?
If there is a server space shortage, I suggest to remove the previous packages after e.g 10 days if no complains heard. With this rollback system we are preventing users not getting stranded when an upgrade doesn't work, not a backup for the sake of it (though its always good to have).
There are different reasons why an upgrade fails. What package maintainers cannot always prevent when there is a defect in the source itself like what happened recently with kdelibs and k3b stopped working for three days. Its fine to have patient and more testers but both also have a limit.
Markku
Offline
So this will mean we'll use twice as much server space?
No, that's why I said you guys are all mistaking it. I'm not going to take the time to explain it. Read how rpm did it. I already said that.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
Basically it works like this:
Xentac keeps a reference to all outdated packages in his head, and if there is a need to downgrade, they are uploaded from his brain (over a high-capacity network link) into the official repository where people can download them as normal.
:-D
Dusty
Offline
i actually worry more about the actual downgrading more than the technical logistics. it is also a wee bit of a out to making sure packages are more thoroughly tested in the first place.
AKA uknowme
I am not your friend
Offline
Read how rpm did it.
<i>To roll back an RPM transaction set, RPM must have access to the set of RPMs that were on the system at the time the transaction occurred. It solves this problem by repackaging each RPM before it is erased and storing these repackaged packages in the repackage directory (by default, /var/spool/repackage). Repackaged packages contain all the files owned by the RPM as they existed on the system at the time of erasure, the header of the old RPM and all the scriptlets that came with the old RPM.</i>
Transactions and Rollback with RPM
http://www.linuxjournal.com/article.php?sid=7034
Markku
Offline
transaction support has been on pacman's long term TODO list for ages now. It's still months away though. Aurelien has been working hard at libifying pacman, so transaction support won't take any shape until after that.
Offline
I have a stupid Radeon, and Stupid ATI doesn't have a stupid driver for XF86 4.4, only 4.3
So for me (E), it would be super duper beneficial to be able to install 4.3. Which I don't really know how to do.
Stupid ATI.
fffft!
Offline
ATI: try x.org from the testing repository OR buy NVidia...
Offline