I guess I’m not the typical FreeBSD user, because I do not enjoy using ports much. Mainly this is because I also use it as a desktop. On a powerful server or workstation, ports is fine. It’s super flexible and everything works quite well. And kudos to all people working on updating and making improvements to it.
However, using ports on my laptop really makes me cry. Why? If I want to install a port, I have to keep a ports tree on my laptop and actually compile everything. Since I have a pretty weak laptop in terms of processing power, this takes ages. But of course, I can install packages! The thing with packages, however, is that it works really well for a release, but when upgrading later on, I always end up in trouble if I try to use the official FreeBSD packages.
First of all, the package sets following each release gets outdated quickly. Second, if I want to update my packages without using ports I get into trouble. There is no real package upgrade tool that I know of, but I can install portupgrade if I want to, because it has a fancy -PP options, telling it to use packages only. But there are issues with this: portupgrade seems to require that you have a ports tree to work. In addition, when you have the ports tree, portupgrade will look for packages matching the exact version that is in ports, and if the package server does not happen to have the same ports tree as you (only one commit updating a port can break this), it fails.
So what is the solution for me, besides writing a pkg_upgrade? Having a ports tinderbox on a different host to build packages for my laptop (I could use official 8-stable packages for instance, but there always seem to be some packages missing, and some not built). And the upgrade procedure? Move /usr/local and /var/db/pkg away, and reinstall packages. It works ok, but looking at how well this can be handled on other systems, it’s a bit silly :/ So, maybe I’ll just have to look closer at the pkg_upgrade idea :)
So, on to the constructive part of this rant^Wpost. There is no need to change everything for this to work better. A pkg_upgrade tool can probably reuse a lot from the other pkgtools, such as version checking and dependency checking. However, the hard part is knowing what version to get from the servers. Luckily, the Latest/ directory contains unversioned tarballs of packages that can be examined to get their version. But again, this requires one to get the packages first in order to examine it. Not very bandwidth-friendly. I think a simple approach would be to keep a version list together with the packages, which could be used by pkg_upgrade to check if any new version of a package exists (much like INDEX in /usr/ports I guess). I haven’t thought about the hardest question yet: how to handle dependencies and package renaming, but I would think one could allow specifying this in the same file.
Update: As i was working against my local package repository, I did not notice that the official package repositories actually contains the INDEX file from the ports tree where the packages are built.
I also think the package building procedures could be changed, because somehow, there are always packages missing (at least several gnome packages last time I tried). I do not know much about this though, but I would advocate for a system where a package was rebuilt on all architectures and supported releases once a commit was made to the affecting port.
There, I feel better now :)
I just learned of sysutils/bsdadminscripts after my previous post about how hard it was to use packages only in FreeBSD. Well, I think I found a partial solution to my problem, as the bsdadminscripts port contains a pkg_upgrade utility, which is able to update your system without a ports tree available, as long as the INDEX file exist on the packages server.
I now use this in combination with my port tinderbox, building the packages I want for my laptop. Then I generate the INDEX file in the tinderbox ports tree, and put it into the packages folder of the tinderbox. Voila! I can now use pkg_upgrade -a, and all packages are upgraded to the latest version.
There are a few things that I think can be improved: Have the tinderbox scripts automatically generate the INDEX file and putting it into the packages directory with a simple command or just do it on an update of the ports tree. The other thing is what I mentioned in my previous post about keeping the official packages properly up to date.
Last year in Japan I bought a Cowon iAudio D2 player, which have proven to be quite good. But a few days ago, I thought I’d try to upgrade the firmware of it. I then discovered that there are four different types of firmware depending on where you bought it. As I bought it in Japan, my firmware was not compatible with other firmwares. The reason for this are mostly due to small differences in hardware. In my case, I have the possiblity of watching Japanese television (not really useful in Norway).
Therefore, I thought I would try and upgrade to the european firmware (a lot more fixes get through to this firmware it seems), but I was a bit afraid I would brick it if it was the case. I looked around at the iaudiophile forums, and finally I found someone with the same attempt, and they succeeded. The procedure was easy, but to be able to use the european firmware, I had to rename them to have the same file name as the Japanese, in order for the player to pick them up. Luckily, it worked for me too. Phew!
As I usually have a few classes at school which requires special software, I wanted to be able to run some of this software on my own computer, as there are student versions of some of the software. One of these is ModelSim from MentorGraphics. ModelSim is basically a simulator for hardware designs, and I use it to simulate VHDL. Unfortunately, ModelSim only comes for Windows, Linux and Solaris. As I only run FreeBSD on my laptop, no software for me :( But wait, FreeBSD have the linuxulator!, which allows Linux binaries to be run unmodified on a FreeBSD host (It is basically an implementation of Linux syscalls within the FreeBSD kernel). The steps I needed to go through to install the Linux version of ModelSim was pretty easy.
First of all, one of the emulators/linux_base* ports needs to be installed. I chose linux_base-fc6, as I’d like the Linux 2.6 support (although I’m not sure if that is actually needed). After installing the port, a linux userland appears in /compat/linux. To make sure I don’t get any problems with programs needing procfs, I mount linprocfs(5) as well.
There, easy! Ready to run linux programs. Now, ModelSim comes with its own installer, which needs a few additional files that you can get at their web-site. However, programs may depend on additional libraries, and this is IMO the most tricky part about the linuxulator. In my case, I got some errors complaining about not finding libXsomething. Luckily, there are a few ports that you can install for the most common libraries. In this case, I had to install x11/linux-xorg-libs. Although a very old version, I was able to run the ModelSim installer and the installed binaries afterwards. Awesome!
Today, I’m sitting in a café in Oslo, waiting until we’re leaving for Gardermoen and our flight back to the Netherlands after one week vacation in Norway. The weather was nice, and I got to do some skiing at least. However, I was actually supposed to be in the Netherlands already. The reason that I’m not, is that we (my girlfriend and I) missed the flight on Sunday. We actually missed it by one day, as we were 100% sure that we were leaving yesterday, so when we showed up at the airport, we were shocked to learn that we were 24 hours late! This was a silly mistake, as neither of us really looked at the date, we always assumed that we were leaving on Monday. Unfortunately, to be able to board the flight that we assumed was our flight, we had to pay 3000 NOK extra per ticket! In other words, we had to find other ways of getting back. Luckily, we got to stay at my sister place last night, and got new tickets for today’s flight at approximately the same price as our original tickets (700 NOK per ticket). Hopefully, we’ll be back in our apartment tonight :)