Hello, Before starting, I'd like to remind that we're all humans, so we can discuss these ideas politely and making use of nothing more than reason. I am NOT a pedantic person looking to impose my will; please, excuse me if you feel I'm doing it. I hope this turns into an interesting conversation, and not into an unjustified battle, as it too often does. Recently, I realized I was not using Arch in the way it was "intended"; I was building most of the packages of my system, much "a la Gentoo", with modified PKGBUILDs and a local repository. While it worked with no major inconveniences, I started looking for truly source-based distros, and found Gentoo. However, I disliked some parts about it. This is my attempt at taking what I consider to be "good" ideas to Arch. **Binary packages are right** It is possible to either build packages by yourself, and then store them for later use, or directly take them in prebuilt form. This is specially useful when time matters or when the machine is unable to build things (in my case, I broke a laptop, and it seems it was because of overheating). **Versioning** If I have understood it right, Gentoo makes it possible to have several versions of the same package through "slots". Consider the following scenario in Arch: bar1 -> libfoo-1.0 bar2 -> libfoo-1.0 `libfoo´ is updated to 2.0. `bar2´ catchs up, but `bar1´ does not. Thus, updating `libfoo´ to the latest version would break `bar1´, but is necessary for `bar2´. The solution I've seen is adding the major version number in the package name (e.g. "gtk2", "freetype2"), which would turn the older version of `libfoo´ into `libfoo1´. I think, however, that we could implement Gentoo's "slots", and add the concept of "alternatives". That way, there would be PKGBUILDs for both versions of the library, each with the same name but different version. Each library would be installed as, say, "/usr/lib/libfoo-${pkgver}.so", and an additional script for handling of the named "alternatives" could then create a symlink at /usr/lib/libfoo.so pointing to the right version _if needed_. The script would exist in a per-package basis, so there would only be one for both versions of `libfoo´. For example: $ alternatives-manager libfoo --choose 2.0 ln -s /usr/lib/libfoo-2.0.so /usr/lib/libfoo.so (The name and syntax is just an example.) This is easier to understand with libraries. With programs, however, it's more difficult; someone could want to install different versions of the same program, or, more likely, an outdated version (a typical case would be GNOME 2). We could add "-${pkgver}" to the name of the binaries in such cases, and then use alternatives to create convenient symlinks. It would be horrible to have "cp-8.9.2" and the like. Packages that could benefit from this are freetype, python, and I guess every library out there. It would be, however, hard to implement. **Package selection** When pacman finds several versions of the same package in various repositories, it fetches the one in the prevalent repo. This implies that, if I've configured my local repository before the official repos, I will never notice that a package has been updated. I'll have to do `pacman -Ss pkg-that-ive-compiled´ to check if there's a newer version, or track each project by myself. I think that, if pacman finds itself in the described situation, it should prompt to ask which package to install, unless --noconfirm is passed, in which case it should stick with the default. [If I do `pacman -S repo/pkg´, however, pacman should have no problem in choosing the package, and it shouldn't ask.] These were all the ideas. If you haven't understood something, please ask. Thanks, Kalrish