packaging Archives - Yet Another Linux Blog

Do Package Managers Spoil Us?

I thought of this interesting question the other day while messing around with Slackware 9.0 which was one of the last versions of Slackware to come on a single disk. The goal was to try to take a Slackware 9.0 install to the most recent stable and it was almost accomplished. Glibc was the largest hassle…and I made it to Slackware 11.0 before something caused things to not boot at all. All things considered, I spent 3 days on trying to get Slackware 9 to current.

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:

Is this direction the correct direction we should be heading?
Are there better approaches to package management that don’t follow the model we have currently (other than Conary)
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!

Foresight Linux and Conary Part I

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.

Continue reading “Foresight Linux and Conary Part I”

The rPath Forum goes Live!

Here at rPath we use our own Mediawiki appliance for documentation (what is a software appliance?). While this is an excellent way of getting things documented quickly (as wiki’s are) it is NOT a great place for community based questions to influx nor a good place for knowledgebase questions to be stored. Often, the discussion tab on wiki’s go ignored with issue tracking systems replacing problems users have.

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 🙂

gmrun and openbox

My friend Og Maciel and I had a short package session today where we updated some openbox items that we use such as Nitrogen for wallpaper, pypanel, and something we didn’t package before…gmrun. Install it with:

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:

Use Foresight Linux? Add Some Spice to Your Life!

Hot on the heels of the .4 beta release of Spicebird and a Lifehacker article previewing spicebird (with many screenshots and functionality tests) I bring you the Conary package available for your consumption. To install spicebird on Foresight:

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.

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

Thoughts on Package Management

The Change in Distro-Land

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.

Continue reading “Thoughts on Package Management”