Debian – Page 74

Save disk space by excluding useless files with dpkg

November 15, 2010 by Raphaël Hertzog

Most packages contain files that you don’t need: for example translations in languages that you don’t understand, or documentation that you don’t read. Wouldn’t it be nice if you could get rid of them and save a few megabytes? Good news: since dpkg 1.15.8 you can!

dpkg has two options --path-include=glob-pattern and --path-exclude=glob-pattern that control what files are installed or not. The pattern work the same than what you’re used to on the shell (see the glob(7) manual page).

Passing those options on the command-line would be impractical, so the best way to use them is to put them in a file in /etc/dpkg/dpkg.cfg.d/. Beware, the order of the options does matter: when a file matches several options, the last one makes the decision.

A typical usage is to first exclude a directory and then to re-include parts of that directory that you want to keep. For example if you want to drop gettext translations and translated manual pages except French, you could put this in /etc/dpkg/dpkg.cfg.d/excludes:

# Drop locales except French
path-exclude=/usr/share/locale/*
path-include=/usr/share/locale/fr/*
path-include=/usr/share/locale/locale.alias

# Drop translated manual pages except French
path-exclude=/usr/share/man/*
path-include=/usr/share/man/man[1-9]/*
path-include=/usr/share/man/fr*/*

Note that the files will vanish progressively every time that a package is upgraded. If you want to save space immediately, you have to reinstall the packages present in your system. aptitude reinstall or apt-get --reinstall install might help. In theory with aptitude you can even do aptitude reinstall ~i but it tends to not work because one package is not available (either because it was installed manually or because the installed version has been superseded by a newer version on the mirror).

Found it useful? Click here to see how you can encourage me to provide more articles like this one.

Debian Squeeze artwork selected by the desktop team

November 12, 2010 by Raphaël Hertzog

It looks like the desktop team has selected the artwork (including wallpaper and GDM theme) for the upcoming Debian 6.0 release.

The winner of the small contest is SpaceFun by Valessio Brito. Included below is the splash screen, click here to see all the pictures.

The other options in the poll were Nightly, Ciel and Lisp Machine. Thanks to the artists who participated in this contest!

But the work is not over yet: while the artwork has been selected, it still needs to be integrated in the system. If you feel like helping by creating a theme for a display manager (GDM/KDM/SLIM) or for the Grub boot loader, please drop a mail to debian-desktop@lists.debian.org (subscribe here).

Be informed early by following me on Identi.ca, Twitter or Facebook.

People behind Debian: Joey Hess of debhelper fame

November 11, 2010 by Raphaël Hertzog

I decided recently to publish interviews from Debian contributors and I picked Joey Hess as my first target. He’s one of the few who have heavily influenced Debian by creating software that have become building blocks of the project, like the debian-installer (Joey uses the shorthand d-i to refer to it).

My questions are in bold, the rest is by Joey (except for the additional information that I inserted in italics).

Who are you?

Hello, I’m Joey Hess. I’m one of the oldtimers in Debian. Actually, I just checked, and there are still up to nineteen active Debian Developers who joined the project before I did, in 1996. I got started fairly young, and am “just” 34 years old.

I spend part of my time working with Lars Wirzenius, another Debian oldtimer, on Branchable. It makes it dead-easy for anyone to make a website that is built from Git, using my Ikiwiki engine to do wiki and blog style things. These days I spend the rest of my time working on free software, when I should really be looking for work to pay the bills.

What’s your biggest achievement within Debian or Ubuntu?

I guess I’m mostly known by Debian developers for writing debhelper and perhaps debconf. Probably founding the Debian Installer project has been a bigger impact for users. I’m fairly equally proud of all three projects. But while it might sound corny, I am more proud of the accumulation of all the smaller things done in the context of Debian. It’s more of a deep connection to the project. All the bugs fixed, and filed, and packages uploaded, and late night discussions, and just being a part of the larger project.

What are your plans for Debian Wheezy?

Hmm, I stopped thinking of Debian releases by code names back around Slink. 🙂 So, few specific plans for Wheezy. The main thing I would like to help make happen in Debian next is Constantly Usable Testing, and it transcends releases anyway. The only specific plans I have for Wheezy are that there will probably be a new debhelper compat level, and I hope d-i will finally switch to using git.

RH: You can learn more about “Constantly Usable Testing” in my article Can Debian offer a Constantly Usable Testing distribution?.

If you could spend all your time on Debian, what would you work on?

Getting Debian on all these computers that we carry around in our pockets and can’t easily run apt-get on and hack on. Phones that is. It’s a bigger problem than just Debian, but I think Debian needs to find a way to be part of the eventual solution. The FreedomBox concept at least hints at a way around the current situation with embedded computers in general.

What’s the biggest problem of Debian?

I believe that the biggest problem is institutional, social and technological inertia. Every specific case of something that frustrates me about Debian today can be traced back to that.

You contribute regularly to Debian mailing lists, yet I don’t remember any aggressive/frustrated mail of you. How do you manage that? Are you avoiding heated discussions?

Rats, sounds like all my wonderful flames of years past have been forgotten!

Seriously though, after I noticed thread patterns, I started trying to avoid participating in the bad patterns myself. Now I limit myself to one expression of an opinion, and I don’t care who gets the last word. If people can’t be convinced, it’s time to find another approach to the problem. Also, code talks.

Most of the programs you wrote for Debian are in Perl. Do you regret this choice?

I love that question! No, no regrets. My only concern is whether the language limits contributors or users. I have not seen Perl significantly limiting the use of anything except for debconf (we had to rewrite it in C for d-i). And I do not notice fewer contributions to my Perl-based code than to other code.

I do sometimes regret when someone tells me they had to learn or re-learn Perl to work on something I wrote. But while I’m enjoying writing new things in Haskell now, and while I hope it will mean less maintenance burden later, I don’t think using Haskell will make it easier for others to contribute to my programs. Anyway, for me the interesting thing about writing a program is the problem it solves and the decisions made doing it. Choice of language is one of the less interesting decisions.

Is there someone in Debian that you admire for his contributions?

Well, lots. You’re tempting me to throw a dart at a map. So arbitrarily, I’ll say Anthony Towns. We could all learn something from how he’s approached making big, fundamental changes, like introducing Testing, and making Debian Maintainers happen.

Thank you to Joey for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter and don’t miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

PS: If you want to suggest me someone to interview, leave a comment or mail me.

5 reasons why a Debian package is more than a simple file archive

November 8, 2010 by Raphaël Hertzog

Folder with gears You’re probably manipulating Debian packages everyday, but do you know what those files are? This article will show you their bowels… Surely they are more than file archives otherwise we would just use TAR archives (you know those files ending with .tar.gz). Let’s have a look!

1. It’s two TAR file archives in an AR file archive!

A .deb file is actually an archive using the AR format, you can manipulate it with the ar command. This archive contains 3 files, you can check it yourself, download any .deb file and run “ar t” on it:

$ ar t gwibber_2.31.91-1_all.deb
debian-binary
control.tar.gz
data.tar.gz

debian-binary is a text file indicating the version of the format of the .deb file, the current version is “2.0”.

$ ar p gwibber_2.31.91-1_all.deb debian-binary
2.0

data.tar.gz contains the real files of the package, the content of that archive gets installed in your root directory when you run “dpkg --unpack“.

But the most interesting part—which truly makes .deb files more than a file archive—is the last file. control.tar.gz contains meta-information used by the package manager. What are they?

$ ar p gwibber_2.31.91-1_all.deb control.tar.gz | tar tzf -
./
./postinst
./prerm
./preinst
./postrm
./conffiles
./md5sums
./control

2. It contains meta-information defining the package and its relationships

The control file within the control.tar.gz archive is the most fundamental file. It contains basic information about the package like its name, its version, its description, the architecture it runs on, who is maintaining it and so on. It also contains dependency fields so that the package manager can ensure that everything needed by the package is installed before-hand. If you want to learn more about those fields, you can check Binary control files in the Debian Policy.

Those information end up in /var/lib/dpkg/status once the package is installed.

3. It contains maintainer scripts so that everything can just work out of the box

At various steps of the installation/upgrade/removal process, dpkg is executing the maintainer scripts provided by the package:

postinst: after installation
preinst: before installation
postrm: after removal
prerm: before removal

Note that this description is largely simplified. In fact the scripts are executed on many other occasions with different parameters. There’s an entire chapter of the Debian Policy dedicated to this topic. But you might find this wiki page easier to grasp: http://wiki.debian.org/MaintainerScripts.

While this looks scary, it’s a very important feature. It’s required to cope with non-backwards compatible upgrades, to provide automatic configuration, to create system users on the fly, etc.

4. Configuration files are special files

Unpacking a file archive overwrites the previous version of the files. This is the desired behavior when you upgrade a package, except for configuration files. You prefer not to loose your customizations, don’t you?

That’s why packages can list configuration files in the conffiles file provided by control.tar.gz. That way dpkg will deal with them in a special way.

5. You can always add new meta-information

And in fact many tools already exploit the possibility to provide supplementary files in control.tar.gz:

debsums use the md5sums file to ensure no files were accidentally modified
dpkg-shlibdeps uses shlibs and symbols files to generate dependencies on libraries
debconf uses config scripts to collect configuration information from the user

Once installed, those files are kept by dpkg in /var/lib/dpkg/info/package.* along with maintainer scripts.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

1. It’s two TAR file archives in an AR file archive!

2. It contains meta-information defining the package and its relationships

3. It contains maintainer scripts so that everything can just work out of the box

4. Configuration files are special files

5. You can always add new meta-information

Tags

Recent Posts