You are not logged in.
-I want to know about which packages you usually prevent from updating?And how to do it?
-With what command i can delete everything the package i have installed?Including config files.
-Upgrading often is more convenient way for ArchLinux?
-If you reinstall or install Arch on other machines,have you written install guide or script for yourself,can you share it?
-Best aides for pacman(yaourt is a good one i know)
Offline
-I want to know about which packages you usually prevent from updating?And how to do it?
man pacman.conf
-With what command i can delete everything the package i have installed?Including config files.
man pacman
-Upgrading often is more convenient way for ArchLinux?
Yes
-If you reinstall or install Arch on other machines,have you written install guide or script for yourself,can you share it?
Yes
-Best aides for pacman(yaourt is a good one i know)
Offline
1-But which packages do you hold?
3-Will you share them?
4-No,i mean like colorizing,numbering the results in pacman in console.
Offline
1-But which packages do you hold?
Holding packages will bring you more troubles in the long run unless you know what you are doing. Given your question, you may not really know.
3-Will you share them?
http://aur.archlinux.org/packages.php?ID=22747 ?
4-No,i mean like colorizing,numbering the results in pacman in console.
Offline
Wow packup seems a great idea. And what about your config files. Do you just copy them to their place or using a program or a script for them?
Offline
Wow packup seems a great idea. And what about your config files. Do you just copy them to their place or using a program or a script for them?
It should be quite easy and straight forward to simply copy them. OTOH, I see more and more people using github to store and manage their dotfiles.
Offline
-I want to know about which packages you usually prevent from updating?And how to do it?
-Upgrading often is more convenient way for ArchLinux?
I've been thinking more seriously about update frequencies recently. Especially considering the varying levels of brokenness I experience which takes quite some time to fix. This includes minor software compatibilities eg. firefox extensions. Or major functionality problems eg. broken suspend. Or worse, superhard to track show-stopping evil bugs.
The consensus seems to be update often and fix/downgrade as you go along.
http://wiki.archlinux.org/index.php/Downgrade_packages
However, if you want to fix stuff less often, you should update less often. Afterall, bugs introduced by bleeding edge packages might be fixed later on even newer ones. Updating less often allows you to see less of these buGs. Of course, this still doesn't solve the issue of experiencing "bugs" when you finally decide to update.
http://arm.nrk.cc/ (More info in the wiki)
To minimise this issue, I'm thinking of using the "Arch Roll back machine". The idea is that you update at a lower frequency of 3 months(variable) and when you finally do update, sync your system 1 week(variable) late. The idea is that by the time you sync, all the show-stoppers or bugs and their "solutions/fixes" are clearly spelt out in forums and the net. Thus, allowing you to fix stuff easily.
On the whole this results in a highly maintainable system which is as bleeding edge as you desire. If you need specific applications to be updated more frequently, just update those alone. Conversely, if you want your all your apps to be bleeding edge but not the kernel and other hardware stuff, you can blacklist those in pacman.conf.
Last edited by onguarde (2009-05-12 11:18:17)
Offline
I some time ago read a writing about keeping up arch servers. Tips there included reading forum for problems other people have had with updates recently... Expecially after important packages(or many) have been updated I'd say it is better to wait a while before updating, unless you are bored.
So far I have been using "Update often and rollback when needed" -method for my Desktop and eee. With my vdr/samba/etc. server I have been updating much less frequently and only after updating Desktop and eee.
Have to admit that sometimes it would be nice to have one more repo for 'proven' packages. Maintaining such in useful way might be bit too worksome, but for server usage I would happily choose such repo. So, it just depends a lot to what system is used and how much time freetime you have.
Offline
Have to admit that sometimes it would be nice to have one more repo for 'proven' packages. Maintaining such in useful way might be bit too worksome, but for server usage I would happily choose such repo. So, it just depends a lot to what system is used and how much time freetime you have.
FTR, all core packages have to be signed-off by at least two developers and will automatically spend some time in testing. That's what I would call 'proven'.
Offline
FTR, all core packages have to be signed-off by at least two developers and will automatically spend some time in testing. That's what I would call 'proven'.
I'd call that 'tested'
Offline