Once upon a time, in the mists of Conary time before we had announced or even named Conary, I had what seemed to me to be a brilliant idea.

I had been comparing various legacy package management systems, and noted that there were several different ways to get different versions of the same package installed on a single system at the same time. In the Debian universe, all packages that might possibly have multiple versions installed (typically libraries, but also other packages) had their version number included in the package. In the RPM universe, older packages intended to coexist with newer packages would have part of their major version included in the package name. In the Gentoo universe, there would be a declaration that there were a certain number of "slots" open for a single package. None of the solutions satisfied me.

My idea was rooted in the fact that Conary is a binary+source version control system including branching. You could consider a branch name to be similar to a "tag" in classical source code version control. I figured that if you put the same "tag" on multiple branches, you meant that they were all designed and intended to be installed in parallel. (Later, we created a special kind of branch called a "shadow", and later still, we deprecated branches that were not shadows, but the concept remained.) We called this "label multiplicity" because you would specify one label for a trove and Conary would put multiple versions on your system. If you really wanted only one of them to be current, you would redirect from the old branch to the new branch, something that Conary supports. Because you have to do something extra to change Conary's idea of what is the most current package, I think of this as the Conary equivalent of click to focus.

In a fairly static universe, that works OK. It is more elegant than including versions in package names or declaring a set of slots. However, reality diverged from theory in a few somewhat related ways.

When we first conceived of Conary, we did not fully realize how good Conary dependency management could be. We knew we could improve over what existed -- after all, we were the people that wrote a lot of the existing dependency management code and were aware of many of its weaknesses as well as strengths -- but we didn't realize just how fully automated it would be. It was not obvious that it would generally work to say "give me a booting system plus these three packages plus everything else required" and expect it to just work most of the time. While we're still improving Conary dependencies to increase our reach into certain dark corners, the truth is that they work very well already.

With this great dependency resolution, plus the relatively new feature of resolving dependencies by searching through groups instead of on labels, there is essentially no need for label multiplicity. The most common use for label multiplicity has been libraries with different interface versions (sonames), and the way Conary automatically breaks up packages, if libraries have different interface versions, they generally install side-by-side with no problem. Because of the new mechanisms for searching for packages that satisfy dependencies, there isn't a need to have a single "tag" produce multiple packages; Conary isn't generally searching for dependencies by the package name or the label, it's searching by the dependency itself.

This reduced the need for label multiplicity, but did not by itself make label multiplicity inconvenient. However, what we have found in practice is that Conary users and developers really don't care what "branch" the software is on. They just want to "tag" the current state. Maybe they start by "branching" (shadowing, in our terminology) a package from rPath Linux, but then later they realize that they want to base their work on a newer version that is included in Foresight Linux. What they really want to do is use the same "tag" (label) for the new "branch" (shadow) and have Conary switch from using the old "branch" (shadow) relative to rPath Linux to the new "branch" (shadow) relative to Foresight Linux. Maybe later they will want to switch to basing on rPath Linux 2. They want the "tag" (label) to reference the latest "branch" (shadow) that has been "tagged".

The more flexible dependency resolution has now made it possible for us to change Conary's behavior regarding tags. When Conary 1.2 is released, it will consider only the latest package on a label to be the most current, regardless of "branch" (shadow). This will not reduce Conary's ability to resolve dependencies. It merely means that when you specify a package name explicitly, you will not accidentally specify multiple packages that you didn't mean to. You won't have to "cook redirects" if you change the source of the software you build into your repository.

As I see it, this is the Conary equivalent of focus follows mouse.

If you want to try this out, we are doing beta test releases of Conary leading up to the 1.2 release on the conary.rpath.com@rpl:1-devel label. You can run the command conary update conary=conary.rpath.com@rpl:1-devel and test it. Please report any unexpected behavior; this is absolutely a beta test and we're certainly not quite ready to release Conary 1.2 ... yet. Your testing will help us get there!