It is possible to upgrade some packages in Arch so something will break. How come this can happen if pacman tracks dependencies?

It's not only possible, breakage from an update is probably inevitable with Arch or any other rolling release. By definition, you are dealing with bleeding edge software that has not been thoroughly tested and which is in a constant state of flux with a rolling release. Bugs are inevitable and sooner or later one of those bugs will break your system.

I don't think you have a clear idea of what a dependency is and that is what is confusing you. From a developer point of view, a dependency is a list of other software packages that must be present and if the required packages are not present, like the correct version of a particular library, the application cannot, and will not, run or compile. The developer has designed his application with reference to there being a set of other software packages present, i.e. the application is not wholly self contained. This set of software packages that the developer requires to be present are the application's dependencies.

Most, but not all, modern distros have packaging systems that automatically check to make sure the packages that the developer has designated as dependencies are present before they will allow the developers application to be installed. If the dependencies are not there, the package management system will automatically download and install the needed dependent packages if possible or spit out an error message if this is not possible. This is no guarantee that the software will be bug free. It just means that the developer designated dependencies have been met.

2 members found this post helpful.

You didn't clearly get my point... Arch developers always recommend to upgrade all packages at once. You must do "-Syu" instad of "-Sy [package1] [package5] [package7]". Some time ago Arch users had problems with pacman which crashed when they upgraded xz package without something else that came upgraded also. Pacman needed xz of certain version and some other package of certain version. xz and another package were available upgraded in repos but some people upgraded xz without another package which they left with an older version. Pacman died. I guess this is dependency thing. Pacman didn't prevent it.

That sounds like a mistake in the packaging rather than pacman i.e. the xz package should have properly specified that the the newer version of the "other package" available in the upgrade repos had to be upgraded along with package xz or the older "other package" should have specified the older xz package as a dependency. Any package manager that resolves dependencies like pacman, apt, yum or urpmi has to have the appropriate data fed into it to do its job properly. Part of properly building a binary package, be it rpm, deb, or tar.xz, is to include the proper specs for the package so the package manager can do its job. From what you describe, it sounds like someone made a mistake in those specifications and a particularly devastating one since it screwed up the package manager making repair of the problem much more difficult. Again, this type of thing is more likely to happen in a rolling release where the packages are changing constantly.

1 members found this post helpful.

sorry, i know this thread's a little dusty now, but i just cant let this go without passing comment...

not all rolling releases are alike. rolling release, does not, by definition, mean bleeding edge, despite what impression using arch may give you of rolling release.

for example, gentoo, when staying with the stable keyword (i.e. the keyword with just your architecture with no "~" prefix, and certainly no "**" keyworded packages), the "probably inevitable" of something breaking, is as diminished as any other stable non-rolling release (maybe more so?). it's stable ("old", farther from the edge), and it's still rolling release. [edit](not to mention the rest of the checks, balances, safeguards, and tools to empower etc that gentoo has to remedy any such update issues, like slots, or painless rolling back of problem packages... not that you see much of that sort of thing when sticking with just stable).[/edit]

sry, i just didnt want to leave that hanging there giving people a bit of a misconception of what rolling release is, or can be.

but yeah... in the context of arch... there is no stable. you're always right up there on the bloodied edge.
.... unless you want to go for archserver, which i think was created to address that problem, so an arch[-like] system could be used in a server environment where such volatility is not welcome. ... but i think it's repo is lacking anything not specifically server-related.
~ i've never used archserver for long enough, so cannot profess to know if it actually does achieve the goal of being able to update arch without relatively high risk of breakages.