People flat out do not understand anything about Conary. What I hear the most:
Why another package manger? Isn’t there already too many of these out there? Why use Conary when I can apt-get? Apt-get is soooo much better. Dpkg gives you sooooo much more than anything could possibly give you. Conary is still beta quality…rpm and deb are much more developed mature.
If the person(s) asking the questions above actually understood what Conary is and CAN do…they would see this is a very limited view of Conary. Not only is conary a package management system vis-a-vis a system that manages EVERY single package of software on your system…it is also a powerful version control system for software packages and packaging. It’s an enabling mechanism for packaging software quickly and easily.
I’d like to go over some of the things I think are great about Conary…clear up some of the “why is this needed” speak by showing how Conary actually gets things right and the common problems experienced by other package managers that it solves.
How Conary Organizes Packages
If you use debian or rpm repositories…you know that inside a repository directory “stable” (as an example) are all the stable packages for your distribution. The packages are versioned according to their upstream version (if the repository maintainers are sane) and maybe arch and revision number. This is done by hand. It is managed by hand. If developers/packagers cross names between repositories you are brought into dependency problems. To illustrate this concept, if you and I both packaged firefox3 and named it accordingly…and someone used both your and my repository…our versions would conflict because the packaging system wouldn’t know which one to install.
Conary takes the manual operation from this…if you use a Conary based system, your repositories ARE VERSIONED. In other words, the repositories aren’t static directories that contain a bunch of packages…they are versioned branches that contain components of software.
These components (packages) are also versioned according to upstream version…but revision is handled automatically by Conary…no manual process. This eliminates the possibility of having two packages named the same exact thing in different repositories. In other words, if Joe Schmoe is packaging Liferea for his apt.joeschmoe.com repository and names his package the same thing as say Joe Smith’s package for Liferea in his apt.joesmith.com repository we run into problems. With conary this NEVER WILL HAPPEN…EVER. This kills about 90% of dependency problems all together.
But what about arch? Arch is architecture…32bit or 64bit…PPC and more. Once again, you’re bit by the possibility of conflicting names across repositories. You’re also limited in the name because a developer has to put the architecture INSIDE THE NAME. Take a look at liferea as an example: liferea-1.2.2-2.el5.rf.x86_64.rpm. Is this easy for an end user to understand? Is it the same as liferea-1.2.2-2.el5.rf.x86-64.rpm?
Conary takes a different approach. Each package has a ‘flavor’ that it is ‘cooked’ (committed) in. There may be a 64bit flavor, 32bit flavor, Xen flavor, and so on. This flavor is visible to the user only if the user requests to see it…and it is NOT inside the name of the package. The package is still called, simply enough, liferea. Revision number, arch, upstream version, etc…are all handled automatically by Conary.
You can see how creating and maintaining software would rely less on a manual process and more on automatic source controlled one with Conary. You can also see how organized Conary is with its packages.
Sources.list Not Needed
Conary is smart enough to remember where you installed what package. There is no need to keep a sources.list. So if you install the package balsa (a Gnome mail client) from my personal repository the command would be:
sudo conary update balsa=caffeine.rpath.org@coffee:venti-1
So now what? Do you have to add caffeine into a sources.list somewhere? Nope. Conary remembers where that package came from and when an update is available later it will find it and notify you. Let’s say you did the same thing for a hypothetical repository for deb or RPM…you’d add in the repository address for where balsa is at. Then you inherit ALL packages listed at that repository…not just a single package. There once again may be problems with package names, versions, and now sources.
Conary elimiates this problem for you as well. A single package is taken from that repository and since the repository is versioned, conary knows where it came from. It knows that it doesn’t need anything else from that repository unless you tell it to install more.
Problems With RPM and Deb
The real problem I see with deb and rpm is monolithic dependency resolution. This is the term I use to describe what happens when you go to install one package and you get over 10 more packages as dependencies. Dependency resolution in RPM and Deb is left up to the developer to find when creating packages.
When packaging software with Conary, dependency resolution is automatically done FOR you. When you ‘cook’ a package, it calls out what dependencies you need to add to your ‘recipe’ (comparable to rpm spec file).
Another important characteristic of deb and rpm is that when you update a package, the old version is completely removed from your system. This means that if a program depends on another that is being removed, you’re out of luck unless it was flagged as a dependency (manually). As you can imagine, large packages like openoffice take forever to upgrade AND packages depending on one another for specific versions might find they have problems interacting. With conary, dependencies are done at the file level…so only the file(s) that requires updating is updated. This saves bandwidth for downloading and saves time for upgrading. It also allows you to get dependency resolution honed to specific files instead of just specific packages. This means that distros CAN become much smaller…that is, if you were making a liveCD and wanted to trim it down to under 200MB you could do so very easily with Conary’s fine tooth dependency resolution and packages that are componentized.
Rollback to Previous
Conary operates using something called changesets. It looks at what is on your system for software and what you want to install and creates a changeset (like a diff) between the two states. This changeset is then installed by the package manager…it reads it, fetches the software the changeset says it needs to install…and then installs it.
What if you installed a group of packages that you don’t want installed anymore? What if something you installed doesn’t work as expected? Rollback 🙂
sudo conary rollback #
where # is the number of rollbacks you would like to rollback to. Each installation action is considered one numbered change for conary. It tracks each installation/removal action and numbers it in a list. You can therefore return to a previous state on your system with ease. See Conary Rollbacks for more information.
I’ve covered quite a bit of information here…enough for a discussion I’m sure. Are there still areas about Conary you’re unsure of? Leave me a comment. Part II will be coming soon that will discuss more topics about Conary and Foresight Linux. I’d like to base Part II on answering questions from the readers.