Respecting backwards compatibility is more complicated than just never removing features from software. Sometimes less is more: extra features can be bad for maintenance, a source of bugs, or a source of vulnerabilities. Sometimes features are added as workarounds or hacks in lieu of a proper solution and serve no real purpose after a later update. It's highly unfair to the pacman devs to claim that removing a makepkg option is a slippery slope towards DRM, Microsoft, and the dark side. If you consider The Arch Way, the pacman update seems very much in-line with the distro. "Arch Linux defines simplicity as without unnecessary additions, modifications, or complications..." A few people have mentioned workarounds for --asroot, so it certainly isn't _necessary_ and the devs seem to think its continued maintenance would be a complication. "Simplicity of implementation, code-elegance, and minimalism shall always remain the reigning priorities of Arch development." This one speaks for itself. "Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system." As mentioned previously, removing --asroot does not remove one's control over the system. At worst it is an inconvenience in an unusual corner case. Our competent users should be able to figure out how to live with the new pacman options. Arch has an especially complicated relationship with backwards compatibility. This isn't the first case of a breaking change in an update, and I think it's actually pretty minor in terms of impact. There's always an outcry when something like this happens, but as long as it doesn't violate Arch's philosophy I think we'll be okay. In keeping with semantic versioning, it would make sense to bump pacman's major version. Max
