Slackware for those of you that don’t know, has no dependency resolving package manager. Previously, a good attempt was made with swaret and that was my first jump into package managers with dependency resolution all together when it came out…but Swaret is no longer being maintained and doesn’t really work well anymore.

Since Slackware has no real dep resolving package manager…it’s one of the last ‘true’ Unix like Linux versions out there. Back in the early to mid nineties…things were exactly like this. If you wanted to update your Linux version…you stepped through it manually and tried to get things to work. What was great about Slackware was making your own Slack packages with source…no dependency resolution but in the process of making the package you’d have all the dependencies eventually installed. In this entire process, you became VERY familiar with your system…how it booted, what run level things occurred at, how cron jobs worked, etc. You were baptized by fire so to speak…you were to sink or swim.

As I said, this got me thinking…do we rely on dependency resolving package managers TOO much? They’re cliché now of course…run of the mill. Back in the 1990′s though rpm was the only true package management system around…and rpm was never designed for internet consumption. The guys who wrote rpm had in mind CD and floppy upgrades. Fast forward to now and we have zypper, pacman, urpmi, deb, and conary…all built with online repositories in mind. Do these managers take the heavy lifting away for new users? Do they spoil them?

Do systems break less with easier resolutions due to package managers? Does it mean that the new user of today won’t be as experienced as the old user of yesterday?

I think it might.

Users in the past had to chip away and reassemble with less documentation and no package manager. This meant that the user of yesterday ripped apart systems and packages to discover how they worked and which cogs fit where.

The user of today follows step by step instructions and the software is given a sane set of defaults by most package developers when said package is installed.

Does this make for lazy users?

I don’t think users are lazy per se…but as previously stated, spoiled ones. And it’s no fault of their own…it’s the direction the software has taken us. Now the questions we need to answer are:

1. Is this direction the correct direction we should be heading?
2. Are there better approaches to package management that don’t follow the model we have currently (other than Conary)
3. Can we come up with a system that doesn’t make new users spoiled?

I think I’m of both worlds…I started off with no package manager but managed to ride the wave of Red Hat 7.2 and above followed by Mand{rake,riva} and PCLinuxOS. I’m both spoiled and unspoiled. I know what it takes to manage a system without a conventional package manager but I also know how much time it can save me to use one. I sometimes find myself wanting less though…less and more. Less time and more hands on gutting the system. I think I’m in the minority though.

How about you, as a reader of this article? Do you think new users are spoiled by conventional package management systems? Do you see solutions or have ideas we can discuss? Is this really just a process we can improve or is there any programming to be done? Please sound off in the comments section!

Related posts:

1. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

Related posts brought to you by Yet Another Related Posts Plugin.

Do Package Managers Spoil Us? originally appeared on Yet Another Linux Blog on May 16, 2010.

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.

Summary

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.

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

Related posts brought to you by Yet Another Related Posts Plugin.

Foresight Linux and Conary Part I originally appeared on Yet Another Linux Blog on April 23, 2008.

The problem with issue tracking systems is they have workflows of their own and often are impartial where they don’t need to be . Wouldn’t it be nice if there was a place where like users of software could come together to ask questions and help each other reach conclusive answers? Hence, the rPath Forum was born.

Stef created the Simple Machines Forum Appliance, which you can install and run in various formats such as VMWare, Xen, ISO, RAW, and even a LiveCD (in x86 and x86_64 bit flavors!). What a wonderful concept…to be able to quickly download and deploy a forum using nothing but a virtualized environment

As some of you know, I’ve chose Simple Machines in the past at MyPCLinuxOS and PCLinuxOS proper to power those communities. Stef and I are excited to power the rPath community with this same wonderful software.

If you are a packager, appliance developer, Foresight Linux user, or are just interested in our products and technologies such as Conary and rMake…come on over to the rPath Forum and register. Drop us a line and say hello

Related posts:

1. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...

Related posts brought to you by Yet Another Related Posts Plugin.

The rPath Forum goes Live! originally appeared on Yet Another Linux Blog on February 1, 2008.

sudo conary update gmrun

I’ve patched the default gmrunrc file so that when it executes, it places itself toward the top right hand side of the desktop. To override this, create a .gmrunrc from the default.

cp /usr/share/gmrun/gmrunrc ~/.gmrunrc

alter the left and top values to move it around on the screen. Width may also be adjusted. You can also use openbox to bind this to Alt-F2 or a key combo of your choosing. Open up ~/.config/openbox/rc.xml and add the following in the <keyboard> section:

<keybind key="A-F2"><action name="execute"><execute>gmrun</execute></action></keybind>

There are also some built in macros for using gmrun that can be found on the homepage here. it’s quite a handy tool and works quite well for openbox Screenshot showing updated nitrogen and gmrun below:

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

gmrun and openbox originally appeared on Yet Another Linux Blog on January 26, 2008.

sudo conary update spicebird=/foresight.rpath.org@fl:1-contrib

What is Spicebird? From the Spicebird.com homepage:

Spicebird is your one platform for many collaboration needs. It provides e-mail, calendaring and instant messaging with intuitive integration and unlimited extensibility.

1. View the Demo
2. See Screenshots
3. Check the Roadmap

Please remember that Spicebird is beta software currently so use it at your own risk. Enjoy!

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

Related posts brought to you by Yet Another Related Posts Plugin.

Use Foresight Linux? Add Some Spice to Your Life! originally appeared on Yet Another Linux Blog on January 15, 2008.

Distros have changed. In the past, they were made up of a small, tightly knit group collaborators working toward a common goal. With distributions today we now have an informal, large group of collaborators…some of which may not even be aware of the main goal of the distro. That informal collaborator may just want package foo version 2.2 included in his/her distribution so that he/she can use it on their desktop. How does that informal collaborator become empowered? How can the developers reap what that collaborator sows and harness the collective collaboration of thousands of informal contributors? The answer for many software projects is version control. But how can this system benefit package management?

What If?

What if you could combine SVN/CVS/git behavior and packages? What if when you build the package properly, it is checked into the software development tree. You’d be eliminating an entire step in the process (i.e. working more efficiently) and you’d reap all the benefits of version control (diff, merge, shadow, exports, rollbacks, tags, logs) with the actual software packages without losing the benefit of working with source or binaries. Thousands of contributions could be made in the form of ready to install packages that are CERTIFIED (see how this is possible later in this post) to work on the distribution. The contributions would come in on a version control branch designed by the distribution developers…say 1-contribs (much like a contribs rpm server would be)…but unlike most distributions, they would be certified to run on your distro before they even hit the contribs server/branch. Imagine the impact that this would have for bug testing alone.

Sound too good to be true? It’s not. It’s Conary and it is getting ready to go to version 2.0. Let’s take a look at some advantages that conary has over traditional package management and how it can empower the end user.

What Are The Advantages?
In standard distro land, packages are tracked by version/name. If you packaged wget 1.0.12, your package would include this version string in the name. What if someone else packages that same software up and names it something different than you did? What does this package with name wget-1.0.12-suse93-i586.rpm have as an advantage over wget-1.0.12-suse9.3-i586.rpm? As you might be able to tell, this is hard for a package management system to understand concepts of older or newer packages and what should be installed on a system. There is no automatic solution to this process in standard distro land. This is done manually by a developer. The developer selects which version of a package is included in the repository.

Regardless, relying on a name that is manually created and given means that dependency resolution with most distributions will break sometime. Repositories end up with version clashes, missed/overlooked patches, clashing names in between distros for the same package. A disconnect opens up between those developers working with packages…not just packages for a single desktop environment but various ones (KDE, Gnome, Openbox) because the only thing that connects them is a SVN or CVS tree. Updates to one branch do not always make it upstream. With conary, this problem is solved. It works using a distributed version tree and therefore changes always flow upstream from various branches that don’t have to be located in the same place as in traditional version control systems.

Ever done an apt-get upgrade and had only half of the packages install before a failure occurs? You may have a broken xorg after that half update was applied. In rpm land, if I updated and didn’t get through all my package installs I may end up with missing dependencies and a broken system. With Conary this NEVER happens. If an update will break the system, Conary automatically rolls back the changes so that your system is in the EXACT state it was when you began the update. This behavior is built into the package manager and happens automatically during attempted updates/upgrades. It can also be manually done to return to a state that existed before the update.

As an example, have you ever installed a group of software from a development/testing repository that you don’t want installed anymore? Don’t want to go through logs to find out what group of software you installed? Can’t remember each and every package name? With conary simply do a sudo conary rollback # where # is the number of updates you want to rollback to and conary will return your desktop to the state it was before that update.

More advantages…let’s say you’re out on rpmbone.net and you’re searching for the latest release of KAlbum. Which one do you pick out of the results

? If you see your distro represented, great! You’re set…until you need to update from that version. Will you remember what repository you got your software from so that you can get future updates? Will you add this repository to your repository sources list? This being the case you’re going to get a whole lotta updates from that new source unless you do some heavy pinning. Wouldn’t it be great if you didn’t have to remember? Wouldn’t it be great if your package manager would manage this for you as well? Conary does this lifting for you. If you install a conary package from a different conary repository, it REMEMBERS for you where you got it. No alteration of sources because there isn’t a sources file. There isn’t a list of repositories to manage. Conary remembers where all your software is from and tracks this as part of the version control.

Let’s say you roll your own rpm and make it locally on your own build environment. Upstream, the package you built is updated to a version above the local rpm/deb you’ve installed. It installs automatically over the top of your change when you update. With conary, this wouldn’t happen…it tracks local installation of conary packages as well and preserves them if you so desire.

There are countless other advantages that I won’t go into here. The advantages that I went over are meant to support the main point of this post which is that you can get more done by combining package management with version control. This turns one developer into many and allows for many collaborators to contribute certified packages into a distributed version tree repository. This is working smarter and not harder.

More Information on Conary

Certified Packages

Knowing as a developer that you’re getting a CERTIFIED version of a package onto a contribution server is a huge amount of stress relief. Certification occurs with the tool rMake, which “facilitates building packages consistently across computers with dissimilar environment”. If you click on the link to the rMake page, you’ll see plenty of the benefits of using such a tool to package software. rMake creates a chroot

and installs the package you are building in that chroot. Since a chroot is a pristine and unaltered environment, all packages can be certified to run in that pristine and unaltered environment. When a package is committed to a conary repository, you KNOW that it worked inside a chroot on a conary based system. Therefore, you have less to worry about with system conflicts. You’ll be able to build and test packages BEFORE they’re even committed to the repository.

With rMake, you don’t have to worry if that package will run on your distro…you only have to worry about the possibility of unforeseen conflicts…package foo won’t drop its use of dbus for package bar and package bar fails…and package bar was just contributed by Joe Schmoe onto your contribs server. This is what distributions SHOULD be allowed to concentrate on…conflicts between packages on an installed system and not dependency resolution or patch management. The place where developers work on conflicts should not be the packages themselves or the repository…it should be the users’ desktop.

Empowerment

Taking the worry that a package committed to the repository won’t work away, developers can empower users. Empowerment is a powerful tool in open source. Often times, a user of desktop linux becomes soured when he/she realizes that something doesn’t fit exactly what they want. For example, Joe Schmoe may want a software suite that isn’t included in the distributions repository. Should they learn how to roll an rpm or package a deb to do this? Can they? Will the developers trust the package when or even if it is submitted to the contribution server? Most likely not.

When Joe created his package, he created it on his local system. Dependencies that are unforeseen will be present in that package because Joe’s system differs from other installed systems. He didn’t package and test with a chroot to make sure that all his dependencies were resolved before submitting his package to the contribution server. If Joe were using Conary and rMake, developers wouldn’t have to worry about whether his package were up to where it needed to be…because in order for him to commit it to the contribs server it would have to have all dependencies resolved and would have to be built in a chroot before it is even submitted.

The ability to package and contribute packages is therefore available to standard users. The package is also IMMEDIATELY available for consumption by that end user…no waiting period for it to trickle down into stable…it was already stable when contributed. When it changes from 1-contrib to 1-devel, conary automagically tracks that move and updates from 1-devel in the future. It’s that smart. Developers are still in the driver seat and can control the overall flow of packages in the repository…the power still rests with them. But conary does all the lifting for them and often times the developer finds themselves letting conary manage things.

Imagine KDE and Gnome desktop distro developers working side by side and sharing fixes/patches and packages of common shared software…remember, with conary repositories, all changes can be seen by both development trees (KDE and Gnome) so the changes are automatic when put in place. Instead of having to push that fix to both branches of software, conary allows for fixes to be automatic between the two desktop development branches.

Work smarter, not harder. Conary can be an incredible tool that can empower users to contribute and merge different development trees seemlessly between various versions of software. Is there a learning curve? Of course! If you don’t know or understand the concepts of version control, you’ll have a bit of an uphill climb when learning conary. When learning to package, you’ll have to understand some of the classes and superclasses that are passed down so you can take advantage of not reinventing the wheel with each package you roll.

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

Related posts brought to you by Yet Another Related Posts Plugin.

Thoughts on Package Management originally appeared on Yet Another Linux Blog on December 12, 2007.

I’m by no means a programmer. I’ve been hired on as a documentation specialist. Yet, Conary is simplistic enough that I can roll my own packages. I’m quite impressed by it’s simplicity and power. If you’d like to help out or are curious about KDE Foresight or the Conary package manager, visit us on freenode #foresight-kde

For those of you wanting alltray goodness…update via Packagekit by searching for alltray OR:

sudo conary update alltray

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...
3. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...

Related posts brought to you by Yet Another Related Posts Plugin.

Alltray in Foresight originally appeared on Yet Another Linux Blog on November 28, 2007.