Well, my example was about a major API change. Another example would be Python: we have version 2 and version 3, and both are used. If we had switched to a Python3-only bleeding-edge setup, we would have ended up with a big breakage. As we needed both, we renamed the old Python to make it able to coexist with the newer version. What I proposed is a scheme in which makepkg, after running package() but before packaging, did something like this: for P in "${pkgdir}/usr/bin"/* ; do mv "$P" "$P-${pkgver}" ; done Although it could break things (e.g.: program calling another program; oh, where is it?), it would allow to have as many versions of the same package as we wanted. (It would probably be better to adjust the paths via 'configure'.) This can be useful in some cases. Aside from the Python example, I could have multiple X servers and seamlessly benchmark each; I could also have two versions of the same library if both are needed. Regards, Kalrish On Jan 5, 2014 8:26 PM, "Leonardo Dagnino" wrote:

...

Hello,

Thanks for your explanation. I understand that it's not possible to maintain every version of a package (and, as you've pointed out, it goes against The Arch Way). However, it could still be useful for AUR

2014/1/5 Kalrish Bäakjen : packages,

...

or even official ones (I can't check it, but I was told that Arch keeps official PKGBUILDs in an SVN repository. If that's the case, then it would be possible to checkout a specific version of a PKGBUILD, for example, to get an old version of X that is compatible with certain drivers).

About libraries, my knowledge is very little. Why do exist the unversioned symlinks? I'm sure I'm missing something (perhaps the linker dereferences links) but, if bar1 links with -lfoo, then, if libfoo is updated and libfoo.so now points to a newer version, wouldn't bar1 break?

I completely agree with Arch's principles. Mainstream has to be pushed to move on and use newer versions of libraries. I also personally loved GNOME2, but I understand it used what we now consider "old" versions of libraries, so it can't be sustained "as-is".

Thanks!

A libfoo upgrade wouldn't break bar1 in most cases (unless there was a major API change), because the external interface stays the same (again, with exceptions). Library updates usually only change the internal implementation and/or add new functions, which means code made for previous versions will continue working. -- Leonardo Dagnino

Maybe a mechanism could be implemented that warned the user…? Or a setting in a per-repo basis. (I understand your point. Indeed it would be awful.) Thanks, Kalrish On Jan 7, 2014 8:56 PM, "Darshit Shah" wrote:

On Sun, Jan 5, 2014 at 9:06 PM, Temlin Olivér wrote:

...

On Sun, Jan 5, 2014 at 3:07 PM, Kalrish Bäakjen < kalrish.antrax@gmail.com> wrote:

...

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

When it comes to your point about *Package Selection*, you're overlooking a serious use case. The [testing] repos. With [testing] and [community-testing] enabled, there are loads of packages which are available in multiple "official" repositories. Asking the user to select which version to install for each of them is a hassle for the end-user and also a new way in which systems can be broken. Instead, what we implement is a repository hierarchy. When you are setting your local repository at the top, you're violating the hierarchy and hence, it is you, the end-user at fault.