Jump to Navigation

A small tool

I wanted a simple thing: install some packages to support my wireless card. It seems I need a non-free driver for that, which is kind of disappointing; but that is life.

In some earlier experiment, I had installed the latest Linux kernel from the unstable archive (I am running stable on my laptop). No big deal, that: I have done it before on earlier Debian releases. There is always a small risk (both in terms of stability and of non-declared dependencies) but one can always decide to go back to the old kernel if there are problems.

Now, though, I had to compile some module code using module-assistant. Of course, it needs the linux-headers version corresponding to the installed kernel. It automatically tries to get it from unstable. No problem. Except...

It seems the linux-headers I need depends on a specific gcc version. The gcc version from unstable. And my package manager sensibly decides not to install that, as it would basically mean a complete upgrade to unstable.

Bummer. Oh well. I can always go back to an older kernel. Or install the one from backports. Talking about that, what other packages do I have installed from unstable? Good question. How does one determine that?

I actually had written a small tool for that, some time earlier. Before upgrading from one Debian version to the next I wanted to answer that same question. That shell script was not multi-arch aware, though. And painfully, painfully slow (as in: a running time of hours on my laptop).
So I reimplemented it in perl. Enhanced it. Debianized it, for easy installation. Wrote a manual page for it. And decided to make it publicly available.

Now it may be that there is already some other great solution for this. There are some package control fields that may give a clue. But I could not find something robust, that can tell you where you got a package from, if the current version is perhaps in both testing and unstable, and that supports whatever apt repository you have in use.

Even if there is a better way to do this, at least I had fun implementing this. Perl is very well suited for this kind of thing, which basically amounts to building an internal representation of both all repository contents and the currently installed packages.

Tags:


Blog_article | by Dr. Radut