[renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

lseubert · 2009-08-28 21:13:02

Ranguvar wrote:

I'm tempted to change the section recommending Yaourt to say to NEVER use Yaourt What do you think?
Yaourt, in the process of installing AUR packages, automatically runs possibly malicious or accidently dangerous code in the PKGBUILDs and install scripts. Especially if we're advocating very few AUR packages for when stability is a concern, Yaourt shouldn't be needed.

I updated the wiki Ranguvar. It still recommends installing yaourt for the SysAdmin features, but it now includes a detailed warning about using yaourt to install AUR packages.

Also, an FYI for those following this thread. Once the kernel26-lts package moves out of testing, and into (I am guessing here) core, I'll include a section on the wikipage about using kernel26-lts to enhance Arch stability.

Ranguvar · 2009-08-28 21:57:34

lseubert wrote:

Ranguvar wrote:
I'm tempted to change the section recommending Yaourt to say to NEVER use Yaourt What do you think?
Yaourt, in the process of installing AUR packages, automatically runs possibly malicious or accidently dangerous code in the PKGBUILDs and install scripts. Especially if we're advocating very few AUR packages for when stability is a concern, Yaourt shouldn't be needed.
I updated the wiki Ranguvar. It still recommends installing yaourt for the SysAdmin features, but it now includes a detailed warning about using yaourt to install AUR packages.

Sounds good I edited it slightly to be more specific, feel free to rephrase what I said or anything.

Last edited by Ranguvar (2009-08-28 22:00:06)

jacko · 2009-08-29 00:10:19

I'll advocate against yaourt too. We are talking about ways to keep a stable arch linux.

Providing a way to install unsupported packages is not a stable approach to administering a Arch OS.

If the user wants to install unsupported packages then by all means, provide them a link to the appropriate wiki page (with great caution). There is already enough wiki articles that explain the AUR and how to use it. We do not need to advocate yaourt anymore then it already is. I think you're losing the scope of the original wiki article by advocating the use of such programs to Provide a stable Arch Linux.

It's been a while since I used yaourt, but what sysadmin features are you refering too? Is there another capable tool that does that one job and does it perfectly? I am kinda hinting at pacnews, which there is an official package/tool for just that, pacdiff. Again stability comes from understanding just as much as it comes from bug free software. Yaourt can't provide either one, if you want my opinion.

Just as an example... "I was following the rock stable arch wiki page and it told me to use yaourt to install packages from the AUR, but yaourt returns with this error... or now something doesn't work the way it once did...yaourt just doesn't work period...etc..." In irc it has all been said before and it will all be said again I am sure.

Yaourt is a great tool if that is what you want to use, but you should understand what it is doing before you rely on such a tool. Again it's just an opinion.

Last edited by jacko (2009-08-29 00:26:12)

lseubert · 2009-08-29 03:58:11

Ranguvar wrote:

lseubert wrote:
I updated the wiki Ranguvar. It still recommends installing yaourt for the SysAdmin features, but it now includes a detailed warning about using yaourt to install AUR packages.
Sounds good I edited it slightly to be more specific, feel free to rephrase what I said or anything.

I edited some of your material, and some of my own, for better clarity. I also included a paragraph about yaourt's SysAdmin capabilities. Finally, I changed the section title to more precisely describe the way I think yaourt should be used on a stable Arch system.

Please take a look and let me know:
A) If this new version resolves the overall concerns you raised, and
B) You are satisfied with the editorial changes I made to the material you submitted:

Enhancing Arch Linux HOWTO.

Thanks for your help with this. I really do appreciate the feedback, from you and other posters. The page is much improved with community input.

Ranguvar · 2009-08-29 04:09:18

Thanks I agree with most of what you did. Clarified just a tad again, and fixed a typo. I just think it important to stress that the install process of an AUR package runs with the same power as the user's shell session, and therefore must be carefully watched.

I think the article is shaping up quite nicely

bangkok_manouel · 2009-08-29 04:21:31

http://wiki.archlinux.org/index.php/Enh … ade_Pacman
chances are that you'll get a pretty much fscked up system one day or another if you follow this advice. one should not sync the db without updating the whole system. if you really want to do that, then download the binary from your mirror.

By default, a routine system upgrade will not upgrade pacman, which is thus prevented from upgrading itself while upgrading other system components.

Not sure what you mean but if you -Syu and there's a new pacman version, pacman will ask to be updated first.

edit: one small comment...
http://wiki.archlinux.org/index.php/Enh … nstability
you may (and most likely will) have to you use the -d flag to do that.

Last edited by bangkok_manouel (2009-08-29 13:15:20)

lseubert · 2009-08-29 04:42:31

jacko wrote:

It's been a while since I used yaourt, but what sysadmin features are you refering too? Is there another capable tool that does that one job and does it perfectly? I am kinda hinting at pacnews, which there is an official package/tool for just that, pacdiff. Again stability comes from understanding just as much as it comes from bug free software. Yaourt can't provide either one, if you want my opinion.

Hi jacko,

About your query on yaourt sysadmin features, please read over the newly revised entry for yaourt, which explains this. I added this material specifically because you raised this question. Also, please note the strong, detailed warnings now present, about the dangers of yaourt. Ranguvar improved that material. Here is the link for your convenience:

Consider Using yaourt to Simplify SysAdmin Tasks.

If I may offer a suggestion, consider installing yaourt and comparing pacdiff and pacnew with pacdiffviewer. I did. Pacdiffviewer is easier to use, and more capable and powerful, with more choices for the user. It makes cleaning up a snakepit of .pacnew and .pacsave files easier. Try it for yourself and see what you think.

That said, I will add the info about pacdiff and pacnew to the section on dealing with .pacsave and .pacnew files. They are capable programs, and ideal for those who don't want to install yaourt. This way, the user will have a choice, which is The Arch Way, yes?

If the user wants to install unsupported packages then by all means, provide them a link to the appropriate wiki page (with great caution). There is already enough wiki articles that explain the AUR and how to use it. We do not need to advocate yaourt anymore then it already is. I think you're losing the scope of the original wiki article by advocating the use of such programs to Provide a stable Arch Linux.

I understand the concern you are raising here. I myself hesitated before adding yaourt to the wikipage. For the reasons I have listed in this thread (see my responses to Ranguvar) and above within this post, I decided to include yaourt.

Why? Because one shouldn't let the perfect be the enemy of the good. You are right jacko, using yaourt on a stable Arch system is not a perfect solution, because the user may abuse it. But it is a good solution for various SysAdmin tasks. To me, the benefits outweigh the risks, and I think you might agree if you try out some of yaourt's sysadmin capabilities, especially the pacman database backup, which is important to maintaining a stable system.

And ultimately, no matter what we write or don't write in the documentation, and no matter how well we write the documentation; users will find a way to screw the system up. There is no such thing as an idiot proof system, or idiot proof documentation.

And empowering users, even to the point of giving them dangerous power, is part of "The Arch Way". I mean, come on, do you know how badly you can hose up a system by directly editing the rc.conf, xorg.conf, and init scripts? And yet, Arch documentation advocates doing exactly that.

Anyway, Ranguvar made the yaourt/AUR warnings in the wikipage much stronger; I included material explaining why yaourt is useful for system administration; and I will add pacdiff and pacnew info to the appropriate section. Do these things help to allay your concerns? If not, please let me know, and let's see if some sort of reasonable compromise is available.

Cheers,
Luke

lseubert · 2009-08-29 05:15:42

bangkok_manouel wrote:

http://wiki.archlinux.org/index.php/Enh … ade_Pacman
chances are that you'll get a pretty much fscked up system one day or another if you follow this advice. one should not sync the db without updating the whole system.

Yup, you're right. My bad. I missed that little detail - although I did catch a few others a while back. Rats. I hate missing the little stuff

How is this for a command?

pacman -S pacman

bangkok_manouel wrote:

Not sure what you mean but if you -Syu and there's a new pacman version, pacman will ask to be updated first.

Yeah, that's what I thought too. I had HoldPkg = pacman, the default, in pacman.conf. And in the last upgraded pacman release, I never got a notice from pacman, and I wound up having to upgrade pacman manually.

Perhaps this was just my system being screwed up in some way. If so, I'll remove that section. What do you think?

bangkok_manouel wrote:

edit: one small comment...
http://wiki.archlinux.org/index.php/Enh … nstability
you may (and most likely will) have to you use the -d flag to do that.

I understand your point about adding the -d flag. Let me toss out some alternative thinking though. What if... the package didn't cause the system screwup, but one of the dependencies, and you had no way of knowing this? In such a case, wouldn't you want the dependencies removed and reverted, just to be sure? This would suggest using the -s flag instead.

Now, pacman -Rs packagename will remove packagename plus dependencies. Am I correct in my understanding that pacman -U packagename will install the older version of packagename AND older versions of packagename's dependencies?

If the answer is yes, what are your thoughts on -Rd versus -Rs - the pros and cons?

bangkok_manouel · 2009-08-29 06:27:40

lseubert wrote:

bangkok_manouel wrote:
http://wiki.archlinux.org/index.php/Enh … ade_Pacman
chances are that you'll get a pretty much fscked up system one day or another if you follow this advice. one should not sync the db without updating the whole system.
Yup, you're right. My bad. I missed that little detail - although I did catch a few others a while back. Rats. I hate missing the little stuff

BTW, I think this may be a good addition to your article (not Sy'ing a single package)

lseubert wrote:

How is this for a command?
pacman -S pacman

That's safe indeed but does it make sense to reinstall the same package over and over again ?

lseubert wrote:

bangkok_manouel wrote:
Not sure what you mean but if you -Syu and there's a new pacman version, pacman will ask to be updated first.
Yeah, that's what I thought too. I had HoldPkg = pacman, the default, in pacman.conf. And in the last upgraded pacman release, I never got a notice from pacman, and I wound up having to upgrade pacman manually.
Perhaps this was just my system being screwed up in some way. If so, I'll remove that section. What do you think?

just FTR:

pacman.conf wrote:

HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg, pacman will ask for confirmation before
proceeding.

lseubert wrote:

bangkok_manouel wrote:
edit: one small comment...
http://wiki.archlinux.org/index.php/Enh … nstability
you may (and most likely will) have to you use the -d flag to do that.
I understand your point about adding the -d flag. Let me toss out some alternative thinking though. What if... the package didn't cause the system screwup, but one of the dependencies, and you had no way of knowing this? In such a case, wouldn't you want the dependencies removed and reverted, just to be sure? This would suggest using the -s flag instead.
Now, pacman -Rs packagename will remove packagename plus dependencies. Am I correct in my understanding that pacman -U packagename will install the older version of packagename AND older versions of packagename's dependencies?
If the answer is yes, what are your thoughts on -Rd versus -Rs - the pros and cons?

your approach is waaaaay more safe. not reverting deps may cause other breakages anyway.

lseubert · 2009-08-29 07:20:47

bangkok_manouel wrote:

BTW, I think this may be a good addition to your article (not Sy'ing a single package)

OK, I now understand the dangers of pacman -Sy packagename - it can get the database out of sync and really hose things up.

Ideally, pacman -S is the solution, as I understand it, perhaps preceded or followed by pacman -Syu if one wants everything up to date.

Now, what about the following command? pacman -Syy packagename

Does that properly take care of the database sync problem normally found with pacman -Sy packagename? If not, I'll drop any further -Syy queries.

If yes, then which is better? pacman -S packagename or pacman -Syy packagename, and why?

Regardless, I will add the material cautioning against pacman -Sy - thanks for catching that.

bangkok_manouel wrote:

lseubert wrote:
How is this for a command?
pacman -S pacman
That's safe indeed but does it make sense to reinstall the same package over and over again ?

No, it doesn't, but given the problems that I had with my system, it was the only way to ensure that pacman was kept up to date. Note that I use yaourt -Syu to upgrade my system, but I don't see why yaourt would not properly handle the pacman upgrade when it comes along.

Unless I hear otherwise from posters to this thread, I'll assume that problem was unique to me, and thus I'll remove the "Update pacman regularly" section as you suggested.

bangkok_manouel wrote:

just FTR:
pacman.conf wrote:
HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg, pacman will ask for confirmation before
proceeding.

Yeah, I know - I read all that back when I first edited my pacman.conf file. You're right. It still didn't work that way for me with the last pacman upgrade. I had to do it manually. Could yaourt somehow be the culprit?

bangkok_manouel wrote:

your approach is waaaaay more safe. not reverting deps may cause other breakages anyway.

OK, so in the section under "Revert Packages That Cause Instability", I'll change the command to 'pacman -Rs packagename', and explain that this removes the package along with its dependencies.

However, I want to be sure about something - what does the 'pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz' command really do when those dependecies are missing?

Yes, this command will install Package-Name. But it will also install dependencies. Where will it install them from? If it automatically installs them from /var/cache/pacman/pkg, that's great. Problem solved - older and stable package with older and stable dependencies are installed

But if pacman goes online and pulls down the latest dependency packages - the ones just removed by pacman -Rs and which might be the source of the instability problems let us recall - then this command doesn't do the job. If such is the case, then I need to write up an explanation about the need to manually install the dependencies using pacman -U /var/cache/pacman/pkg/Name-of-Dependencies.pkg.tar.gz

Do you understand my reasoning here? Am I missing anything?

bangkok_manouel · 2009-08-29 07:41:23

lseubert wrote:

bangkok_manouel wrote:
BTW, I think this may be a good addition to your article (not Sy'ing a single package)
OK, I now understand the dangers of pacman -Sy packagename - it can get the database out of sync and really hose things up.
Ideally, pacman -S is the solution, as I understand it, perhaps preceded or followed by pacman -Syu if one wants everything up to date.
Now, what about the following command? pacman -Syy packagename
Does that properly take care of the database sync problem normally found with pacman -Sy packagename? If not, I'll drop any further -Syy queries.
If yes, then which is better? pacman -S packagename or pacman -Syy packagename, and why?
Regardless, I will add the material cautioning against pacman -Sy - thanks for catching that.

the problem is that you may install packages that have been built against other packages that are still out of date on your machine. therefore none of the above is safe (-Sy or -Syy). syncing should imply a full upgrade. it may be harmless most of the time but you _will_ face major breakage one day or another. FTR, -Syy will just force the rebuild of your db.

lseubert wrote:

bangkok_manouel wrote:
just FTR:
pacman.conf wrote:
HoldPkg = package ...
If a user tries to --remove a package that's listed in HoldPkg, pacman will ask for confirmation before
proceeding.
Yeah, I know - I read all that back when I first edited my pacman.conf file. You're right. It still didn't work that way for me with the last pacman upgrade. I had to do it manually. Could yaourt somehow be the culprit?

not using yaourt, i dunno, sorry.

lseubert wrote:

bangkok_manouel wrote:
your approach is waaaaay more safe. not reverting deps may cause other breakages anyway.
OK, so in the section under "Revert Packages That Cause Instability", I'll change the command to 'pacman -Rs packagename', and explain that this removes the package along with its dependencies.
However, I want to be sure about something - what does the 'pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz' command really do when those dependecies are missing?
Yes, this command will install Package-Name. But it will also install dependencies. Where will it install them from? If it automatically installs them from /var/cache/pacman/pkg, that's great. Problem solved - older and stable package with older and stable dependencies are installed
But if pacman goes online and pulls down the latest dependency packages - the ones just removed by pacman -Rs and which might be the source of the instability problems let us recall - then this command doesn't do the job. If such is the case, then I need to write up an explanation about the need to manually install the dependencies using pacman -U /var/cache/pacman/pkg/Name-of-Dependencies.pkg.tar.gz
Do you understand my reasoning here? Am I missing anything?

you'll need to reinstall everything from cache.

edit: to avoid redundancy, you may link the downgrading section to http://wiki.archlinux.org/index.php/Downgrade_packages

Last edited by bangkok_manouel (2009-08-29 08:11:07)

dolby · 2009-08-29 12:22:07

http://wiki.archlinux.org/index.php/Rock_Stable_Arch_Linux_HOWTO wrote:

Select the Core and Extra Software Repositories
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.

Nice one. I love this part.
Community isnt really part of Arch unless you accept the fact that Arch doesnt care about distributing vanilla packages . Cause a part of community is patched for features and noone cares.

Also i propose you add a paragraph about kernel26-lts.

Gen2ly · 2009-08-29 12:44:43

Great the new name is alot better. Nice work putting the wiki together. Just my opinion but, could you just name the page "Enhancing Arch Linux Stability"? I say this because the old Gentoo wiki did the HOWTO thing and pretty much everything on the wiki had the title "HOWTO dns", "HOWTO build a router", since the Arch wiki is instructional doesn't really seem necessary.

Last edited by Gen2ly (2009-08-29 12:45:55)

jacko · 2009-08-29 13:41:01

Yes, if you want to install a new package there is two ways of doing it. -S <package> to get the version that is in your local sync database, or if that fails -Syu <package>.

I infact ran into this exact issue when kde4.3 was released. I had qt installed so it was not updated when I did a -Sy kde. This then caused an error, because one of the programs depended on a newer version of qt with an update libphonon that was not installed in the previous qt version. I filed a bug because I thought the PKGBUILD should depend upon a specific version, which would easily solve the problem. To my surprise the developer/maintainer disagreed, because not all packages in kde needed to depend upon that specific version of qt. Instead the advice was, to ALWAYS update (-Syu) before installing any new packages that may NOT be in your local sync database. Because depending on specific versions of packages can also bring about unwanted behavior and should be avoided at all cost unless it's absolutely a neccessity.

Hope that makes sense, just to expand upon bangkok's point a little bit.

As for yaourt, maybe I'll take it upon myself to port yaourt sysadmin features to a seperate program. But until I try my hand at it...

Last edited by jacko (2009-08-29 13:42:18)

Ranguvar · 2009-08-29 16:23:20

Yep! Looks great, lseubert, thanks.

lseubert · 2009-08-29 17:57:07

Ranguvar wrote:

Yep! Looks great, lseubert, thanks.

Thank you - much appreciated

dolby wrote:

Community isnt really part of Arch unless you accept the fact that Arch doesnt care about distributing vanilla packages . Cause a part of community is patched for features and noone cares.

I was not specifically aware of that - I assumed that community packagers tried to adhere to Arch packaging standards. Why do the TUs decide to allow packages into community that do not conform to Arch policy? I can see letting such issues slide in the AUR, but shouldn't the standards be a bit tighter for community?

dolby wrote:

Also i propose you add a paragraph about kernel26-lts.

It is already written. I have embedded the following section into the wikipage. For now, it is commented out so it doesn't show up. Once kernel26-lts migrates from testing to core/extra, I'll activate it. I have been reading the mailing list threads and emailing the packager. The inclination is to put the package into core, but they want to check with the Arch installer people first to make sure it fits onto the CD. That, and some further testing is merited. Let me know if this section needs revising:

===Install the kernel26-lts Package===
The kernel26-lts package is a special kernel package based upon Linux kernel 2.6.27 and is available in the core/extra respository. This particular kernel version enjoys long term support from a group of Linux kernel developers, including security fixes and some feature backports. Additionally, this package is specially configured for use with Arch and includes ext4 support. For Arch users seeking a long-term support kernel for use in a server, or who want a known stable kernel as a fallback kernel in case a new kernel version causes problems, kernel26-lts is the answer.
The kernel may be installed using pacman or yaourt. It will be necessary to edit either [[Grub| GRUB]] or [[Lilo| LILO]], depending on which bootloader is used, to make this kernel available as a boot-time option.

Gen2ly wrote:

Great the new name is alot better. Nice work putting the wiki together. Just my opinion but, could you just name the page "Enhancing Arch Linux Stability"?

Done. Good point - the name is better now.

P.S. That's the second name change guys - I hope you all like the name now, because I am not inclined to change it again.

lseubert · 2009-08-29 18:21:59

bangkok_manouel wrote:

the problem is that you may install packages that have been built against other packages that are still out of date on your machine. therefore none of the above is safe (-Sy or -Syy). syncing should imply a full upgrade. it may be harmless most of the time but you _will_ face major breakage one day or another. FTR, -Syy will just force the rebuild of your db.

jacko wrote:

Yes, if you want to install a new package there is two ways of doing it. -S <package> to get the version that is in your local sync database, or if that fails -Syu <package>.

Got it - both -Sy and -Syy suck for upgrading packages. I will make that explicit when I rewrite that material.

Now, between pacman -S packagename and pacman -Syu packagename, what are the pros and cons of each when installing a package. I understand the difference in what they do - one installs based upon the local pacman database, while the other installs based upon a synchronized and updated database. Aside from that, is there any reason to prefer one over the other if you just want to do a plain old install of package Foobar?

jacko wrote:

Instead the advice was, to ALWAYS update (-Syu) before installing any new packages that may NOT be in your local sync database. Because depending on specific versions of packages can also bring about unwanted behavior and should be avoided at all cost unless it's absolutely a neccessity. Hope that makes sense, just to expand upon bangkok's point a little bit.

OK, I understand why it is a good idea to run pacman -Syu before running pacman -S packagename. However, I don't recall this little tip being explicitly stated in any documentation. Is my memory faulty, or is the documentation faulty?

bangkok_manouel wrote:

lseubert wrote:
this command will install Package-Name. But it will also install dependencies. Where will it install them from? If it automatically installs them from /var/cache/pacman/pkg, that's great. Problem solved - older and stable package with older and stable dependencies are installed
But if pacman goes online and pulls down the latest dependency packages - the ones just removed by pacman -Rs and which might be the source of the instability problems let us recall - then this command doesn't do the job. If such is the case, then I need to write up an explanation about the need to manually install the dependencies using pacman -U /var/cache/pacman/pkg/Name-of-Dependencies.pkg.tar.gz
you'll need to reinstall everything from cache.
edit: to avoid redundancy, you may link the downgrading section to http://wiki.archlinux.org/index.php/Downgrade_packages

OK. I'll edit the page to make sure all of this is clear. Thanks for the link - that will help a lot.

jacko wrote:

As for yaourt, maybe I'll take it upon myself to port yaourt sysadmin features to a seperate program. But until I try my hand at it...

Whoa! Before you do, consult with the yaourt maintainer. I seem to recall reading on a thread somewhere that plans were afoot to rewrite yaourt and even name it something else. Perhaps the rewrite could include a change that would make AUR installs an optional setting in the .conf file? If so, maybe you could collaborate with those guys to produce something new. The pacmatic guy might want to do the same - he has some good ideas on new features for package managers. And hey, while you're all at it, why not just work on pacman itself, adding new features to it, along with that relational database that everybody has been talking about for years

Gen2ly · 2009-08-29 21:19:19

lseubert wrote:

P.S. That's the second name change guys - I hope you all like the name now, because I am not inclined to change it again.

sand_man · 2009-08-29 23:22:13

If you are worried about stability then you should avoid AUR. If there is something in AUR that you need, by all means install it but there is no need to use yaourt. yaourt is great for ease of use but as Ranguvar said, it has the potential to run malicious code if the user is not careful.

Allan · 2009-08-29 23:23:28

I think the "Revert Package Upgrades That Cause Instability" instructions are poor... They boil down to:

pacman -Rs Package-Name
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz

Firstly, "pacman -Rs" will not work when the problem package is a dep of another package. And -Rd should be on the commands to avoid list... And if you reinstall a whole chain of packages, you will not know which caused your problem.

I think it would be much better to advise to do a "pacman -U pkg" or if needed "pacman -U pkg1 pkg2 pkg3..." until the issue is solved by downgrading as few packages as possible.

DonVla · 2009-08-30 00:03:22

come on, guys!
1) "Enhancing Arch Linux Stability -> Consider Using yaourt to Simplify SysAdmin Tasks ????"
if you want to _enhance_ stability, don´t use yaourt _at all_.
2) if you want to have a "rock-solid" arch system, i´d suggest to setup and use your own repository for critical packages rather then having two or more lines of "IgnorePkg" entries.
3) "Use Recommended Configurations" + "Select the Core and Extra Software Repositories" = start using debian...
4) " Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible." what does this have to do with stability? qt apps do not crash, because gtk is installed... at least here on my machine.

if you want to have a stable system set up an own repo with _working and stable_ versions of packages. that´s how i handle this. sure, you have ti keep track of dependencies, but you have to do this anyway.

i use metapackages to downgrade critical packages and their dependencies. i describe this on this thread:
http://bbs.archlinux.org/viewtopic.php? … 64#p588564

and last but not least: trust only tools you´ve written yourself.:D
vlad

zodmaner · 2009-08-30 03:41:15

dolby wrote:

http://wiki.archlinux.org/index.php/Rock_Stable_Arch_Linux_HOWTO wrote:
Select the Core and Extra Software Repositories
Edit the /etc/pacman.conf file to use only the core and extra repositories. These software repositories contain the most well developed and tested Arch packages. If need be, also activate the community repository, but be aware that software from this repository might not be as mainstream nor as well tested and packaged as software from core and extra. Only use AUR and 3rd party repositories if absolutely necessary. Avoid any use of the testing repository, or individual packages from testing.
Nice one. I love this part.
Community isnt really part of Arch unless you accept the fact that Arch doesnt care about distributing vanilla packages . Cause a part of community is patched for features and noone cares.
...

Don't you think this suggestion is a bit too excessive?

I mean, sure there are a lot of poor quality PKGBUILD in AUR, but stll there are a number of PKGBUILD that are very well made and work great.

Also, from my personal experience, packages in community isn't really that "not well tested" or "not mainstream" compare to those in core or extra. Aside from patching issue that dolby mentioned, quality of packages in community repository isn't that different than those in core and extra. Hell, a lot of current packages in community used to be in core or extra.

In short, you can't "judge" quality of a package by which repositories it's in. You have to look at the package's PKGBUILD itself to do that.

I also agreed with DonVla about the article's comment on GTK and QT:

Avoid installing multiple desktop environments or window managers. Do not install software packages that duplicate the functions of already installed software. Try not to mix GUI toolkits - stick to an all GTK or all QT system if possible. Keep the system spare and lean.

Are these comment about having a lean system or stable system? Because I think you're confusing the two issues here.

Install GTK and QT together doesn't make system more unstable, nor install packages that have duplicate functionalities (I have both Firefox and Uzbl installed, how will that make my system more unstable?). I mean, since when is having a buggy software installed also make your other software more buggy? It is very _very_ rare to find a buggy program that, when crash, will take the entire OS down with you (this isn't Windows, mind you). Just ask around the forum (or IRC) and you will see that there are tons of people install multiple DE/WM and have very little or no problem at all.

In fact, I will even go so far as to say that having a multiple DE/WM should be semi-encourage, since if your current DE/WM (or whatever) have a fatal bug/crash that can't be recover from, you can switch to your other DE/WM and continue your work.

I'm sorry guys, I know you put a lot of effort into this, but this part about GTK/QT and "don't install software with duplicate functionalities" is simply just a bad, nonsensical, advise.

Last edited by zodmaner (2009-08-30 08:12:43)

lseubert · 2009-09-01 12:52:58

Allan wrote:

I think the "Revert Package Upgrades That Cause Instability" instructions are poor... They boil down to:
pacman -Rs Package-Name
pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz
Firstly, "pacman -Rs" will not work when the problem package is a dep of another package. And -Rd should be on the commands to avoid list... And if you reinstall a whole chain of packages, you will not know which caused your problem.
I think it would be much better to advise to do a "pacman -U pkg" or if needed "pacman -U pkg1 pkg2 pkg3..." until the issue is solved by downgrading as few packages as possible.

OK Allan. Since I reverted your changes to consider another option, I'll revert it back to what you originally proposed.

Also, I'll also be sure to add the warning against -Rd in the "Pacman commands to avoid section". Please take a look at that paragraph and edit if needed.

lseubert · 2009-09-01 13:06:36

sand_man wrote:

If you are worried about stability then you should avoid AUR. If there is something in AUR that you need, by all means install it but there is no need to use yaourt. yaourt is great for ease of use but as Ranguvar said, it has the potential to run malicious code if the user is not careful.

Hmm, maybe I don't understand something here.

I understand that installing a PKGBUILD from AUR can result in malicious code being run on my system. And thanks to Ranguvar's editing of the wikipage, exactly how this is done is made very clear. A clear warning of the dangers of AUR and its PKGBUILDS is now on the Enhancing Arch Linux Stability wikipage.

But sand_man, you seem to make the case here that yaourt alone has the power to run the malicious code in a bad PKGBUILD. Is this really the case? Can not makepkg or any of the many AUR Helpers also run the malicious code found in a bad PKGBUILD?

My point here is that while yaourt can be misused, so can any other tool used to access AUR. And if you read the Consider Using yaourt to Simplify SysAdmin Tasks section all the way through, I think you will find that these dangers are thoroughly explained, along with information on how to avoid them.

If you do not find this material sufficient, please edit it so that it is.

bangkok_manouel · 2009-09-01 13:19:21

http://wiki.archlinux.org/index.php/Enh … n_Commands
this will sound obvious but I think it is be a bit misleading in the article. it is absolutely safe to run pacman -S <pkg> (only -Sy /edit: or -Syy/ <pkg> is evil), you don't _have_ to -Syu first. the only problem you may encounter is that the pkg is not found because it has been replaced by a newer version and therefore is not available on the mirror anymore.

Last edited by bangkok_manouel (2009-09-01 13:25:38)

Arch Linux

#26 2009-08-28 21:13:02

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#27 2009-08-28 21:57:34

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#28 2009-08-29 00:10:19

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#29 2009-08-29 03:58:11

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#30 2009-08-29 04:09:18

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#31 2009-08-29 04:21:31

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#32 2009-08-29 04:42:31

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#33 2009-08-29 05:15:42

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#34 2009-08-29 06:27:40

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#35 2009-08-29 07:20:47

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#36 2009-08-29 07:41:23

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#37 2009-08-29 12:22:07

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#38 2009-08-29 12:44:43

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#39 2009-08-29 13:41:01

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#40 2009-08-29 16:23:20

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#41 2009-08-29 17:57:07

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#42 2009-08-29 18:21:59

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#43 2009-08-29 21:19:19

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#44 2009-08-29 23:22:13

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#45 2009-08-29 23:23:28

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#46 2009-08-30 00:03:22

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#47 2009-08-30 03:41:15

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#48 2009-09-01 12:52:58

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#49 2009-09-01 13:06:36

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

#50 2009-09-01 13:19:21

Re: [renamed - again, sort of] Enhancing Arch Linux Stability Wikipage

Board footer