You are not logged in.
Hello. I guess some of you have already thought about it, but still, here's a simple (in my humble opinion) way of implementing transactions.
The actual thing this will do it to build a package of the current software package before upgrading. Since pacman's package format is not so complex, this shouldn't be hard to implement.
Pacman saves a list of files owned by each package. The only problem occures when a package has some installation scripts. I think it should be fairly easy to make pacman save these installation scripts in its cache as well. Since these are fairly small, and not so common anyway, it should not make a harddrive space issue. When you upgrade, before the new packages are installed, pacman will look for the current files owned by a package, including its installation scripts and will create a package out of it, stored in a /var/cache/pacman/revert dir or something similar.
And well, that's pretty much it. If the user wished to rollback it will simply install these packages over the new ones.
The only issue which comes to my mind is what if a user changed the original configuration file. Well, since this is a rollback feature, it is assumed that the package worked correctly before, with it's custom configuration file, and so there's no real problem.
Anyway, I'd like to hear your take on this.
Thanks.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
Umm...don't people ever keep backups?
I mean, if you keep backups of packages, then what is the need to roll back? Just uninstall the new version, and install the old version that you have saved..along with your saved config file...
*has an image of people running amok in the world willy nilly with no backups*
eep!
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
The way you've proposed to do this will work. Reconstitution of packages should be an incredibly easy addition to pacman (though I am guessing that it will actually end up being a feature of makepkg), and implementing transactions based on that is trivial.
The question is, do we need it?
Offline
The way you've proposed to do this will work. Reconstitution of packages should be an incredibly easy addition to pacman (though I am guessing that it will actually end up being a feature of makepkg), and implementing transactions based on that is trivial.
The question is, do we need it?
this was proposed in the mailing list. I think there may be a post on the User Contrib forums too - adding a option to makepkg that would regen a package. Judd mentioned he'd look into adding it
Offline
that horse just ain't dead yet eh?
there are ways to roll back without ever having to impliment extra code. but to make matters so much easier being impatient and dropping packages in that are big important and not really tested just wait a few days. see if there are bugs and then install or whatever. everyone should know by now the maintainers try hard to capture bugs before release but they are sometimes sloppy (more often than they should be) and big bugs get through.
AKA uknowme
I am not your friend
Offline
Some packages simply contain software which is bugged for some and not for others, in that case a rollback feature will be of use. Such include the new j2re and nvidia's drivers.
Kernel upgrades also apply. And the same for xorg in some cases.
There are some issues that you can't really run away from, that's why I think a rollback is useful.
As far as testing is concerned, I think that people who are couragous enough to use testing would like such a feature just in case.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
I for one, vote to not add extra complexity to pacman. Keep it simple and working.
If you want rollback, just save your previous packages. Uninstall the current, reinstall the previous.
This is after all, a distro for people who know something about Unix, is it not?
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Well, I do not think it adds extra complexity to pacman, as all it does is simply tarring up the existing files before installing the new ones.
And again, some issues are beyond the user to solve. Take for example the issue with the new nvidia drivers and occasional kernel issues.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
*scratches head*
if a user cannot solve it somehow, then how is pacman to solve it?
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I mean, some issues are not related to bad configuration, but to bad code.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
This is a great idea that should be implemented.
I've experienced loads of packages that wouldn't work for me in one version but the prior ones gave no trouble. And it wasn't an issue of packaging but flaws in code.
I don't consider it a problem to implement and don't see any additional complexity in use.
All users would profit from an automated backup function.
Offline
This is neither a new idea (http://bbs.archlinux.org/viewtopic.php? … t=rollback) nor an unresolved suggestion (http://bbs.archlinux.org/viewtopic.php? … t=rollback).
It will be done and it will probably be done similar to how you've said it.
If you don't code or haven't looked at the pacman code, please don't guess at how difficult something is. Especially when people are in a position to believe that your guess is correct.
I wonder how many more times people will bring up the same idea and suggest the same thing without actually reading the old suggestions...
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
rollback through rebuild is a killer feature and as Xentac says it's been discussed for along time,
you probably has to recode both pacman and makepkg to make it work so it will take while to do it,
Ex. Mozilla 1.8 is out and you want to try it and your current version is 1.7. But just to be safe you want to rebuild 1.7 instead of just nuke it during the installation.
This code nuke 1.7
# pacman -S mozilla
This code rebuilds 1.7 and put it in your cache
# pacman -Sr mozilla
This is my understanding of it. Feel free to correct it.
arch + gentoo + initng + python = enlisy
Offline
Well I didn't think of the actual specifics, just the material for the rollback. Could be manual, automatic, as you wish. My vision was that before every upgrade pacman will automatically back things up. It could be every package or only user specified, I've no idea.
There could be a -Sr feature, in fact. And then other functions will actually wrap around it.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline
This is neither a new idea (http://bbs.archlinux.org/viewtopic.php? … t=rollback) nor an unresolved suggestion (http://bbs.archlinux.org/viewtopic.php? … t=rollback).
It will be done and it will probably be done similar to how you've said it.
If you don't code or haven't looked at the pacman code, please don't guess at how difficult something is. Especially when people are in a position to believe that your guess is correct.
I wonder how many more times people will bring up the same idea and suggest the same thing without actually reading the old suggestions...
Sorry, must have missed it somehow. My apologies.
Some PKGBUILDs: http://members.lycos.co.uk/sweiss3
Offline