2004-07-01T20:44:37ZFluxBBhttps://bbs.archlinux.org/viewtopic.php?id=5174ATI: try x.org from the testing repository OR buy NVidia...]]>https://bbs.archlinux.org/profile.php?id=7042004-07-01T20:44:37Zhttps://bbs.archlinux.org/viewtopic.php?pid=33429#p33429I 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.

]]>https://bbs.archlinux.org/profile.php?id=14422004-07-01T19:26:54Zhttps://bbs.archlinux.org/viewtopic.php?pid=33424#p33424transaction 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.]]>https://bbs.archlinux.org/profile.php?id=32004-06-17T07:33:52Zhttps://bbs.archlinux.org/viewtopic.php?pid=31554#p31554Xentac wrote:

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>

]]>https://bbs.archlinux.org/profile.php?id=1182004-06-17T04:00:21Zhttps://bbs.archlinux.org/viewtopic.php?pid=31526#p31526i 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.]]>https://bbs.archlinux.org/profile.php?id=202004-06-16T23:18:00Zhttps://bbs.archlinux.org/viewtopic.php?pid=31481#p31481Basically 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.

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.

]]>https://bbs.archlinux.org/profile.php?id=1182004-06-16T17:30:41Zhttps://bbs.archlinux.org/viewtopic.php?pid=31415#p31415So this will mean we'll use twice as much server space?]]>https://bbs.archlinux.org/profile.php?id=8322004-06-16T16:23:54Zhttps://bbs.archlinux.org/viewtopic.php?pid=31400#p31400There'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.

]]>https://bbs.archlinux.org/profile.php?id=1452004-06-16T16:11:20Zhttps://bbs.archlinux.org/viewtopic.php?pid=31398#p31398I'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

]]>https://bbs.archlinux.org/profile.php?id=7042004-06-16T15:58:44Zhttps://bbs.archlinux.org/viewtopic.php?pid=31395#p31395Another 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

]]>https://bbs.archlinux.org/profile.php?id=6272004-06-16T15:43:42Zhttps://bbs.archlinux.org/viewtopic.php?pid=31391#p31391personally 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).

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

]]>https://bbs.archlinux.org/profile.php?id=6272004-06-16T12:11:27Zhttps://bbs.archlinux.org/viewtopic.php?pid=31360#p31360I 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.