What is Openbox?

From the Openbox homepage, “Openbox is a minimalistic, highly configurable, next generation window manager with extensive standards support.”  From using it, I often think of it as fluxbox-like with the benefits of being able to dip into Gnome or KDE for the items that I want to use.  Your desktop will then run with speed and simplicity using only the elements you want to use with it.

So…Let’s get Started…

This How-To will assume that you’re running Foresight Linux, you’re logged into Gnome and that you’re familiar with conary, the package manager for Foresight.  First and foremost, install openbox:

[devnet@lostlap Desktop]$ sudo conary update openbox obmenu obconf

This installs the needed components to run Openbox on your system. Openbox is minimal by default though so if you login to the environment now for the first time, there will be no taskbars, nothing…just a large blank area for you to work with. We will need to install some extra components to give a bit more functionality. If you’d like a panel menu, I recommend using tint2. I used to use pypanel which is a small panel written in python but this panel is no longer developed.

There are other panels that are packaged with openbox in mind for Foresight; fbpanel is available, which is a very fast and functional menu bar. I like lxpanel also, which is fbpanel with some easier configuration options. For a full list, please see openbox documentation. For our purposes here, we will install tint2:

[devnet@lostlap Desktop]$ sudo conary update tint2

Now we need to copy the default configuration file for tint2 so we can build our panel to our liking.  You’ll have to create the default path for the tint2rc configuration file.  To do this and copy the config file:

[devnet@lostlap Desktop]$ mkdir -p ~/.config/tint2/
[devnet@lostlap Desktop]$ cp /etc/xdg/tint2/tint2rc ~/.config/tint2/

Now tint2 has a configuration file in place and is ready for Openbox to start.

Let the Configuration Begin!

The hard part (install) is now out of the way thanks to the conary package manager. Now we need to configure Openbox so that it’s ready for us when we log out of Gnome. The configuration files will need to be copied to /home/user/.config/openbox.  Of course, this path doesn’t exist yet so we’ll need to create it like this:

[devnet@lostlap Desktop]$ mkdir -p ~/.config/openbox/

Visiting there now will show that there aren’t any files in this directory.  The file we’ll absolutely need to place there is autostart.sh. Other files that will be in here are rc.xml which is for obconf (openbox configuration) and menu.xml (openbox menu system).  We’ll copy menu.xml from a default copy there later.  The other file should auto-create when loading for the first time (rc.xml)

The autostart.sh file is what starts all of our services and our tint2 panel we just installed as well as setup our wallpaper and other items.  Instead of going through the options you can place in here, I’m going to share my autostart.sh to get you up and running quickly.  Please note that if you chose not to install fbpanel and use the gnome-panel or other panel instead, you’ll need to comment the pypanel line below and uncomment what you’ll be using:

[devnet@lostlap Desktop]$  cat autostart.sh
# This shell script is run before Openbox launches.
# Environment variables set here are passed to the Openbox session.
##############################################################
# Panel Section
##############################################################
# pypanel, my favorite panel for openbox
#(sleep 3 && pypanel) &
# Use the wbar Launcher if you would like.  Don't forget to install it before uncommenting
# wbar &
(sleep 3 && tint2) &

#############################################################
# Gnome Integration Section
#############################################################
# This section let's Gnome give us some of its desktopiness
gnome-power-manager &
nm-applet --sm-disable &
/usr/libexec/gnome-settings-daemon &
gnome-volume-manager --sm-disable &
gnome-keyring-daemon &

###########################################################
# Other Add-on's for Openbox
###########################################################
# Make your wallpaper restore to last setting using Nitrogen.
nitrogen --restore &
parcellite &
volumeicon &
################################# End ###################

Download my autostart.sh

To create the menu system file for openbox, we’ll copy from the default installation to our .config/openbox directory (so we can use obmenu…otherwise, that command will give us an error) so use the following command in a terminal:

[devnet@lostlap Desktop]$ cp /etc/xdg/openbox/menu.xml ~/.config/openbox/

Now you’re ready to login and reap what you have sown Logout of Gnome and change sessions in GDM to Openbox.  Notice that your tint2 panel starts up and has the gnome applications we recorded in the autostart.sh file above running and docked! You can add more options to your autostart.sh file and you can also edit tint2rc (in your /home/user/.config/tint2 directory) to store settings for your panel.

I’ve Installed and am Running, Now What?

Now you get to customize the Openbox menu with your favorite applications. Menus are activated by right clicking anywhere on the desktop. There are a few default applications…I choose obconf right away so that I can choose a theme I like and increase the text size since I’m using a high resolution. After that is done, I right click for the menu again and go to applications >> xterm. When the terminal pops up, I type obmenu. From there, I’ll be able to edit my right click menu.

Now instead of entering obmenu in a terminal each time, let’s add it to our right click options. In the obmenu window that you opened in the last paragraph, expand the Openbox 3 option. Find obconf and highlight it. Click ‘new item’ and add obmenu for a label, execute for action, and obmenu for Execute. This will add obmenu to your right click options so you don’t have to open a terminal each time to do things. You can also customize any of the items you find in applications…I put a few things I normally need such as thunderbird, firefox, gnome-terminal, etc. Feel free to add whatever you need…you can have many submenu’s . It’s setup is pretty straightforward.

Nitrogen, the wallpaper manager, requires a small tweak as well to get working. What I did was create a /home/username/Photos/Wallpaper directory and then loaded it up with my favorite desktop wallpaper. Good places to go for cool wallpapers are desktopography.com and vladstudio.com.  Next, install Nitrogen:

[devnet@lostlap Desktop]$ sudo conary update Nitrogen

After your first login, you’ll need to add a menu entry using obmenu to call the nitrogen browser. So create the menu entry and the action you call is:

nitrogen /home/username/Photos/wallpaper

Of course, replace ‘username’ with your users name.  This will allow you to open up all the wallpaper photos inside of that directory.

So What Have we Done?

Today, we’ve installed Openbox on Foresight Linux. We’ve given it a tint2 panel so we have a place to dock applications and we’ve customized the Openbox right click menu and added a wallpaper program called Nitrogen. Hopefully, this shows you the customizable features of Openbox and also shows you the speed that Openbox operates at. It’s a very minimalistic environment, yet one that can be very powerful.

Installation Notes of Interest

tint2

Tint2 is my newly crowned favorite panel for openbox.  It’s lightweight and is able to be configured in so many ways.  I added the sleep command inside my autostart.sh to make sure that the desktop is loaded before the tint2 panel tries to load…mostly, this is due to network manager wanting to animate while the panel loads.  This isn’t as much problem with tint2 as it is with pypanel (see below).

pypanel

Some things I’ve noticed when running openbox…network manager has problems with pypanel. I added the sleep command inside my autostart.sh and this is much better now…but there may be similar problems with network manager. It’s really NM searching for a network and it causes the panel to flicker a bit. Not a real show stopper.

Gnome-panel

Gnome-panel running inside openbox causes a few errors to pop up when I login. This could be due to the fact that I’ve started things in my autostart.sh out of order…I’m also not all together sure what is causing these errors. The problem seems to be with the docking area of gnome-panel as when I minimize programs they are not docked. Easily fixable, but annoying nonetheless.

Alternative Panels

There are quite a few alternative panels out there.  Fbpanel is one.  Perlpanel is another.  Fbpanel and lxpanel are available in the Foresight repositories. You can also add other launchers like wbar if you so desire.

Screenshot

Openbox on Foresight

Installing Openbox on Foresight Linux originally appeared on Yet Another Linux Blog on May 30, 2010.

Foresight Linux is the exception.

Now, this isn’t because they don’t WANT to have a Live CD…they do.  The problem is that rPath, the creators of rBuilder Online, have discontinued the Live CD image creation type.

There was no announcement…no news posting…no clue dart thrown toward Foresight for this discontinuation.  There was only a comment on a single bug in the rPath issue tracker just this past May…Formally discontinued…which in my opinion, is a HUGE mistake as far as community goes.  Why? Because a community is a solid base on which to stand for any distribution or toolset for open source.  rPath has essentially dismissed a feature that the community would find valuable and in the process alienated anyone who finds this feature valuable or desirable.  But I’m not here to talk about whether or not people want to develop their own distributions on rBuilder Online using rPath tools nor the incentive to do so…I’m talking about Foresight. 

So, what incentive does rPath have to help Foresight by fixing it?  Not much…I’m sure there will be those that argue: “rPath has customers and their first allegiance needs to be to them” and those people would be right.  But can’t the Foresight community pick up the torch for Live CD building  on rBO and develop it as a community effort?  Can’t a license be found that it can be released under that would prevent forking?  Can’t it be modularized as a ‘plug-in’? I don’t pretend to know the answer to those questions…I just think that Foresight will continue to suffer as they have been for many, many months now with respect to not having a Live CD.

I’m sure that there will also be those out there saying “but Foresight has a bunch of Virtualized Images to choose from!! No one really cares about a Live CD!!” and I’d say you’re halfway correct.  Developers don’t really care about a Live CD…but those that Foresight attempted to attract…the end user…they DO care about having something they can ‘try before they buy’.  It is my belief that Foresight would be a crap-ton more popular if they had a Live CD.

So What Solutions Are There?

I don’t think rPath will suddenly fix the broken Live CD creation in rBO.  I don’t think they’ll release the code anytime soon (though this is more likely than a fix).  So in the meantime, what if Foresight helped out with LiveCD project that recently was taken over by Unity Linux?  Both Unity and Foresight are Red Hat like distributions and use similar file structures and OS organization.  I think that if Foresight were able to integrate LiveCD onto the distribution, a huge niche would be filled.

Where to Start?

Being involved both with Foresight Linux and Unity Linux gives me a unique perspective on what areas of collaboration could be developed.  One thing is for sure…having both distro development teams onboard would be a huge boon to LiveCD development…and Foresight could suck in SRPMs quite easily from Unity to hit the ground running right away.

I am by no means offering to be the head of this project because I can’t even begin to know where it would start or finish.  I’m just offering a workaround to a problem I’ve seen Foresight have for longer than it should have.  I know the Unity Linux guys would welcome anyone wanting to get involved with helping LiveCD development.  Would Foresight be open to this?  I can’t answer.  I hope so…Foresight needs a Live CD if it hopes to attract more people to it…and that’s something I’m keen on seeing.  Is this something you’d like to see as well?

Foresight, rPath, LiveCD, and Unity Linux originally appeared on Yet Another Linux Blog on October 14, 2009.

Foresight is toying with the idea of having a sub-project (completely separate from Foresight Linux base) that it has tentatively called ‘boots, a Fedora remix‘ (a play on Dora in Fedora for those of you with kids).

What would happen is that mirrorball, a tool from rPath that ‘sucks in’ repositories, would pull in a Fedora repository into a separate Foresight repository.  From there, it is fully consumable by any product/project that is hosted on rBuilder Online from rPath.  Conary really is one of the most innovative package managers on the planet and I’ve mentioned it once or twice before (never got around to part II on one of those though).  The ability to fully suck in a RPM repository is already being done with CentOS and Scientific Linux on rBuilder Online…even Ubuntu is currently being done as well…so we have proof that it is totally possible.  Once imported, Conary takes over the management of said packages.

So what does this give Foresight?  A few things:

1. Testing of packages in 2 communities
2. Developer eyes/chatter in 2 communities
3. The ability of Foresight to cherry pick packages from a large base
4. Compare and contrast for packages from 2 different sources to track down bugs

So, as I said, I was wrong initially and I hope this clears up what Foresight plans to do.  A sub-project will be started that imports the Fedora repository changing them from (rpm to Conary) allowing Foresight to both test and cherry pick packages from a larger base hopefully freeing up a bit more time for Foresight architects.  Phew!  What a mouthful, run-on-sentence that was!

Why Conary?  How does this help Fedora?

I know some of you may be asking Why Conary?  What does it have over RPM that Foresight should suck in a repositoroy and change it to Conary packages?  The reason this is an absolute necessity is because the tools on which Foresight are built (rBuilder Online) works with Conary only…that means ISO generation and repository hosting are all mandated to be Conary based.

The other interesting part about this is that Conary blends version control with package management.  It deals with changesets as packages.  Imagine SVN…you have a local changeset that  you’re working on and the version inside the SVN repository differs from that.  You can then diff the state of your local copy to see how it differs from the remote copy.  This allows you to see the changes you’ve made and allows you to see what code may be broken.  Also, commits are numbered automagically so that you don’t have to worry about breaking things much because you can rollback to a previous known good state.

The same is true with Conary…you can rollback to previous known good states.  You can also diff each changeset locally with the remote repository.  Now imagine this with Fedora packages…if something is broken, chances are Foresight will find a fix for it much more quickly than someone in Fedora…a single command can diff the previously known good version with the broken version and find out the shortcoming.  Or perhaps a known good verion in Foresight that isn’t Fedora based might be used to diff the Fedora RPM version and find out the differences in them.  In all, it’s going to help developers track down problems faster.  This helps Fedora…they now have a small number of Foresight developers who will be working with hundreds of popular Fedora RPMs looking to see if they work or are broken.

Most of the benefit will be measurable in Foresight because they’ll be able to use just about any package Fedora creates…but the Foresight community is FULL of very capable developers…guys that really know what they’re doing.  If they can make this a collaborative effort Fedora will gain exceptionally smart developers as well…even if testing packages on a different platform, they’ll have eyeballs on these packages and if a fix is found or made for them they will definitely go upstream to Fedora.

Hopefully, this puts things right from my initial wrong.  I don’t claim to be an insider for Foresight…I just know a lot of the people involved and ask questions a lot….I also pay attention to the developer mailing list.  If you have any questions, please leave a comment and I’ll attempt to track down answers for them

Clarification on Foresight and Fedora originally appeared on Yet Another Linux Blog on September 9, 2009.

Last week it was reported by LWN and a few other Linux news sites that Foresight Linux may employ a change of direction…that is, create a spinoff project that places the Conary package manager onto a Fedora Linux base. Michael Johnson, Director of Operating Systems at rPath (which maintains the Conary based package manager Foresight uses) summed up his post nicely:

“I think that Foresight needs to be based on an upstream distro that is regularly fully updated and refreshed, and that is maintained by distro specialists with experience and expertise that is just plain missing within the Foresight development community. That distro needs to be imported into a Conary repository; that will allow Foresight to continue to use Conary to manage the process of building a set of consistent modifications relative to that upstream distro, providing a true rolling release. That would allow Foresight developers to concentrate on only the problems inherent in integrating the very latest development source against a recent base that is relatively close to the basis on which the software is maintained.”

Michael also said that it made sense to do this based on Fedora because Foresight is very Fedora-like in filesystem and the way that things are setup and handled in the guts of the operating system (paraphrasing from what I remember of IRC discussion).  Also, in a comment on the LWN thread, Michael states that Foresight, if spinning off with Fedora, would still make use of “Conary, rMake, rBuilder, rBuild, and other rPath technology” and would still use Conary as its package manager which means…it wouldn’t leverage rpm and yum to keep things up to date on it.

An independent project that Foresight maintains sounds like a HUGE undertaking…(even though I’m assured repeatedly by developers from Foresight that it won’t be because it’s “automatic”).  I’ve seen automagic things in the past that won’t cause a lot of work turn out to be quite a bit of work-that-is-not-work.  I find this especially odd when the main complaint is that there aren’t enough OS specialists around…it sounds a bit too large to undertake.  This project actually sounds like it possibly would usurp Foresight Main (Foresight Proper…Foresight Linux…whatever you call it) which is based on the stable rPath Linux and not on cutting edge Fedora like the “boots remix” would be.  Therein lies the problem.  The”boots, a fedora remix” would consistently be ahead of Foresight in development if the project is started and makes progress.  Foresight will continually lag behind it.  Can a 100% guarantee be given that Foresight can snipe packages from “boots, a fedora remix” that would always work?  If not, what does Foresight gain by maintaining the project/spinoff?

I think Foresight won’t be able to maintain an independent project based on Fedora along side of the main Foresight Linux project.  Sure, they may be able to at first…but then what happens when things break?  Is one person responsible? 2? more than 2?  I think instead of having a separate project, Foresight might want to completely base off of Fedora.  This topic is extremely unpopular with Foresight developers though.

Whether or not Foresight adopts “boots a Fedora remix”  is yet to be decided.  It will be set before the Foresight Linux Council at their next meeting.  Hopefully, they take into consideration the amount of manpower a separate project like this would encompass and maybe consider the benefits of adopting Fedora completely as a base for Foresight.

On a similar note, António Meireles, a lead developer for Foresight Linux, has posted what direction he would like to see for Foresight Linux 3…the future major release for Foresight.  With improved underlying architecture that is more inline with Fedora…he may be looking along the same lines that my post here is.  Whatever the case may be, it’s obvious that Foresight is starting to show a flurry of both interest and activity which is a benefit to it.

So where does this leave Fedora?  They’ll benefit from having a lot of knowledgeable developers in Foresight and a few engineers from rPath working with a Fedora based project.  Foresight has a great upstream relationship with the projects it encompasses…like Gnome and rPath.  I would imagine this continued professionalism and cooperation will continue should Foresight base on Fedora.

ClarkConnect Becomes ClearOS

In other news, some of you may or may not know that ClarkConnect will become ClearOS and will be completely open source.  The Clear Foundation will be sponsoring the development of ClearOS which is ClarkConnect re-branded with improvements.  See the full announcement here.  Also, a Forum Announcement Here.  This brings a lot to the table including renewed commitments to documentation, community, and the operating system as a whole.  The change is set to happen in the late part of 2009.

So what does this have to do with Yet Another Linux Blog?  A few years ago, I wrote a review of ClarkConnect 3.2 for home users.  It was well received and still gets many hits even today.  Since I’ve used ClarkConnect since version 2.1 and continue to use it today for my home network…who better to take a look at how ClearOS will measure up?

With this in mind, I contacted the guys over at the Clear Foundation and they agreed to let me blog a bit about some of the changes and improvements that will be happening with ClearOS over the next few months.  So look for more exclusive information from ClearOS in the near future.  They’ve also asked if I’d be interested in helping out with some community endeavors they will have going for ClarkConnect and ClearOS users.  Exciting stuff!  ClarkConnect has really needed this shot in the arm for about the last 2 versions…they lost a couple of really good websites with FAQ’s on them.  It’ll be great to get the community involved with this fantastic Home Server distribution.

Foresight and Fedora, ClarkConnect Becomes ClearOS originally appeared on Yet Another Linux Blog on August 27, 2009.

I have decided – after running Foresight for two months – to no longer use Foresight Linux on my systems. Let me say however that I found the experience interesting and dare I say – challenging. Everyone in the IRC channel was great – very friendly – and most tried to be helpful.

I thought it might be helpful and instructive to provide an explanation as to why I am not going to use Foresight any longer, rather than just disappear. Hopefully, in doing so I may contribute to Foresight becoming a better distro that I might want to run in the future. So, here goes ….

Concerns With Foresight Linux

Conary: When you read about conary it all sounds very exciting and innovative with many really good features. However – when you install Foresight and actually use conary – it doesn’t take too long to realize that unless you are a developer or very involved packager – very little of conary’s goodies really touch you or help you (with the exception of rollback).

However – it’s negatives do impact you as a user:

1. It is very complex and difficult for the average user to understand and use with any effect
2. It is hard to locate individual packages and make sure you have what you need when things are failing to work right
3. The idea of ‘group’s puts numerous things together making it somewhat confusing to sort out when a dependency is not met for an app you really need.

Development and QA: To be very honest – the development of this distro ‘seems’ from my perspective to be done as a fun project – almost a ‘toy’ if you will – for the creator and a couple of his ‘close’ friends. Everything seems to be about advancing to the next version of things – the constant cutting edge challenge of adding in the latest or something really new – without ever really QA’ing and stablizing the existing released code. So problems users are having never really get fixed properly. And this leads to the next concern ….

JIRA: This is the issue tracker for Foresight.  By and large – it appears that issues that don’t personally effect the developers are ignored. I personally have an issue in the tracker concerning sound – which has been there for over 30 days and no one has done anything with it. I finally figured out what was causing the break – but it requires the devs to fix the code. But they have not – and ignore the issue because it works fine for them. Many people have complained about sound issues – but the developers are concerned always with developing the latest code for the next cutting edge release instead of stopping to fix the broken code and solve problems. Poor QA – poor response to user problems.

Conclusion: So – Why Use Foresight? Given the above issues that concern me, I must ask the inevitable question – “Why use Foresight then?” And frankly – I can come up with no compelling reason to do so. Outside of cutting edge gnome – it offers me nothing I cannot get elsewhere – in debian or slackware or archlinux, etc. And those distros are more stable – address issues that are legitimate user concerns – work hard to QA their distros – and in general put out a more user friendly product. The truth is – it’s all linux. So what really counts then is product presentation – QA testing – responsiveness to user problems – and stability providing the ability for the users to do actual work with their linux systems without always trying figure out why something doesn’t work. These things all need real work in Foresight Linux.

The result for me then is that I have returned to Debian. I wish only the best for Foresight Linux and it’s developers and users. I hope some of the issues that have led to my decision will be addressed and that one day I might come back and give it another go. I believe there’s a lot here to like and a great deal of talent. Thank you for your patience with me.

Sincerely,

Theoden

An Open Letter to Foresight Linux originally appeared on Yet Another Linux Blog on March 16, 2009.

I was able to backpedal to the 2.6.27.5-3 kernel and had all of my sound problems automagically fix.  I’m not sure what the problem is, nor how to fix it…but I do know that I’m not the only one with sound problems as of late.  I also know that no one is motivated to fix things right now…as a developer in Foresight, I have heard nothing about a fix for this problem and even my own bug postings have went without comment.

I am attempting to draw attention to this through this post and also by creating a rollup bug listing for all sound related problems in Foresight Linux 2.  If you have a problem, please visit http://issues.foresightlinux.org and file an issue there and drop a comment on my roll-up issue FL-1931 letting me know you’d like to link up to it.

Until that time, I’ve enjoyed the silence for 1 1/2 months.  Some users are going on 6 months.  I hope we can fix this major problem.

Broken Sound in Foresight Linux 2.0.? originally appeared on Yet Another Linux Blog on February 13, 2009.

Taking this into consideration, last year I created a Foresight Linux search engine.  (You can bookmark this at http://bit.ly/foresight-search-engine because the Google url is quite long)

This search engine is Google powered and searches the following locations for you:

1. http://wiki.rpath.com/wiki/*
2. http://foresightlinux.org/*
3. http://wiki.foresightlinux.org/*
4. http://issues.foresightlinux.org/*
5. http://planet.foresightlinux.org/*
6. http://planet.conary.com/*
7. http://lists.rpath.com/*
8. http://forum.foresightlinux.org
   

The interface is a single search blank that returns results from the aforementioned 8 sites.  Google indexes those domains and searches through them for you, making it much easier to find what you’re looking for.

If you’d like to give it a try, you can visit the link above.  On the front page of the search engine, you can get code to embed this search engine on any web page or add it to your google homepage as well.  Hopefully, this search eninge will come in handy for Foresight Linux users.

The Foresight Linux Search Engine originally appeared on Yet Another Linux Blog on February 6, 2009.

I’ve been working with a lot of different distributions out there the past few days and haven’t found one that I like that has KDE 4.2 packages.  Experimenting further brought me back to my old friend Conary and Foresight Linux.  For those of you that don’t know what Conary is, I’ve written a Part 1 (I never finished Part 2 as I changed jobs and haven’t found the motivation) on what Conary attempts to accomplish and a bit of background on how it does things.

When I think of Foresight and rPath Linux along with Conary, I come to a direct comparison to Arch Linux…because pacman is quite similar.  The main difference is that Foresight does a lot more for you out of the gate than Arch does…and arch is quite a bit faster than Foresight.  Still, I decided to give KDE 4.2 a go on Foresight to see how it’s been progressing.

 The first thing I needed to do was to change from the 2 branch of Foresight to the 2-qa branch.  The reason for this is that 2-qa houses python 2.6, which is needed for KDE 4.2.  Until python 2.6 is pushed into the stable branch of Foresight, you’ll need to move your installation to the 2-qa branch.  First, using your favorite text editor, edit /etc/conary/config.d/foresight file.  Inside that file, you’ll see next to the line InstallLabelPath the following:

installLabelPath foresight.rpath.org@fl:2-kernel  foresight.rpath.org@fl:2 conary.rpath.com@rpl:2-qa

change this to the following:

installLabelPath foresight.rpath.org@fl:2-qa-kernel  foresight.rpath.org@fl:2-qa conary.rpath.com@rpl:2-qa

or you can substitute 2-devel there if you’d like to move to the 2-devel branch:

installLabelPath foresight.rpath.org@fl:2-devel-kernel  foresight.rpath.org@fl:2-devel conary.rpath.com@rpl:2-qa

Now, let’s migrate the system.  Migration to a different branch will result in moving your system to become EXACTLY like the branch you’re migrating to.  That means that any custom applications you have installed may be removed…conary will make your system become EXACTLY what 2-qa says it should.  This is the reason I recommend performing these tasks with a fresh install before customizing.

Change with the following command:

sudo conary migrate group-gnome-dist=@fl:2-qa --keep-required --resolve

Don’t worry, 2-qa is not as unstable as it sounds…the most unstable branch of Foresight is 2-devel.  To compare these branches to Debian, 2-qa is like testing while 2-devel is like unstable. 

I installed Foresight Linux 2.0.6 Gnome using a DVD on a Dell D630 Latitude.   Next, I like to uninstall the stuff that is extra in Gnome that I don’t use (you could say, I strongly do not like these):

sudo conary erase transmission f-spot evolution evolution-exchange tomboy banshee

With those packages out of the way, I did a full update.

sudo conary updateall

Some early Foresight 2.0.6 kernels cause random disconnects for my wireless chipset on the Dell Latitude D630 (Intel Pro Wireless) but after the upgrade this symptom isn’t present.  The default 2.6.27.5 kernel made way for the 2.6.27.10 and it seems to work for me quite nicely.  I did notice that the 2.6.27.10 kernel had some sound abnormalities for me with the Intel HDA sound card…so I rolled back to the 2.6.27.5 and things worked great.  See this issue for more information on this sound issue.

Now we have a completely “useable” Gnome system on our hands…but we can’t have that unusable system now can we? (easy Gnome supporters…tis only a joke).  Let us get a real desktop like openbo…er…KDE on there!  Before I got too far though, I wanted to make sure I could play mp3′s and other restricted format items so I installed the codecs needed:

sudo conary update group-codecs

Once this has finished, let’s get KDE 4.2 up and running.

sudo conary update group-kde4=kde.rpath.org@fl:2-kde4.2-devel

Once that command has completed, you should be able to logout and log back in to KDE 4.2.  The most recent builds of KDE 4.2 include python 2.6…something that Foresight Linux has been slow on the uptake with due to conary being written in python.  I’m still working on testing everything…I’m not sure how well this newest build works.  Look for a status update in a few days on this…

Foresight Linux and KDE 4.2 originally appeared on Yet Another Linux Blog on February 3, 2009.

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.

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

Those of you interested in helping us develop, package, or use KDE are welcome to join us in IRC #foresight-kde freenode.  Plans are to build a 3.5.9 Stable version and wait until 4.1 is released to push out a 4.1 version.  Of course, we’ll have 4.0.X builds available for testing and fun all the while   Please, lend us a hand and file those bug reports!

Foresight KDE Alpha-Alpha-Pre-Alpha-Pre Screenshot originally appeared on Yet Another Linux Blog on April 22, 2008.