By the way Ioni, even you forgot about taking care pacnew files. This is why we should let computers do these routinue events.

Yes, I certainly updated.

But I never use the -f switch.

Unless you tell me to, of course!

I use cower for this. It handles dependencies and checks for updates but only downloads the packages, it doesn’t install anything.

[1] http://projects.archlinux.org/pacman.git/commit/?id=0d2600c575033774485f84ad67cbc602592237ab

As regards udev: the fact that this was caused upstream is really no let-out. If ArchBang and archlinuxfr are to be held responsible for their choices of software and their release timings, then that has to hold good for distros like Arch. If a new udev (or whatever) is broken – well, please just refrain from inflicting it on us. And, where necessary, please give us a way out. In this case the problem appears wider and deeper than has been discussed. It is on-going and is certainly not restricted to asynchronous firmware loading problems. And it has been going on for quite a while. Never mind, that is another problem, after all.

Incidentally, if you really mean for us never to use pacman -f, well, don’t provide it! (No, that switch was required recently, I know, but the abbreviation -f could always be disabled as a disincentive.)

Regards

3rd party repositories should take care of about our users. I’m talking about ArchBang and archlinuxfr users that had hard time updating their systems after latest libpng rebuilds because the maintainers considered that cairo-ubuntu suites them well as a replacement for cairo and in case of archlinuxfr, awesome and cairo-xcb.

I do not have anything against them, what I’m against is about delaying rebuilds for days and let their users to fix their broken systems by themself.

Now about the udev thingy. My post covers only packaging bugs and not upstream bugs. The boot delay issue was caused by udev that changed the way firmware is loaded and some kernel modules, mosly wireless, are broken by design and they don’t permit loading firmware asyncronius.

As a user of yaourt, but I would never consider replacing a “stock package” from another source. Yaourt is great for managing those packages which are not available from core, extra or community. At no time have I had a problem with a package installed from aur via yaourt. Most certainly I could not have done better, via makepkg than yaourt did. And I would continue to use archlinuxfr – at the very least for their excellent Verbiste. Nor can any distro forbid the use of third party repos, unless the distro can categorically state that it offers every single useful or desirable package. Not too practical, I think. Not even for Debian.

Indeed, I would suggest that the “Arch way” specifically leads to the the philosophy behind yaourt and its friends. If we could not extend the functionality of Arch with external software, then we would be in a very sorry state.

However, I cannot claim that Arch “stock packages” have never caused me any problems. Of course they have. Nobody is perfect. There is a fairly obvious example which is affecting many users right now – udev hanging on boot, anyone? (That is not the first, and it probably won’t be the last.)

But none of that is the depressing part. In 16 years of Linux usage I have watched more than one distro go down the route of devs ranting at how external software allegedly ruins their perfect work. It always ends in tears. Please, if you have a genuine problem with the compiling directives of yaourt (which I doubt) please sort them out privately. Don’t start hitting out at your best clients.

Good luck with perfecting the excellent Arch, but, please, be gentle with you supporters.