apt-get install debian-wizard

Insider infos, master your Debian/Ubuntu distribution

  • About
    • About this blog
    • About me
    • My free software history
  • Support my work
  • Get the newsletter
  • More stuff
    • Support Debian Contributors
    • Other sites
      • My company
      • French Blog about Free Software
      • Personal Website (French)
  • Mastering Debian
  • Contributing 101
  • Packaging Tutorials
You are here: Home / Archives for Debian

What Debian & Ubuntu topics would you like to read about?

October 27, 2010 by Raphaël Hertzog

A woman enjoying this blogAfter having looked back at the first months of this blog, I also want to look forward and see how I can improve its content. If you’re a Debian/Ubuntu user and/or contributor, I want this blog to be a truly useful resource for you. What kind of articles would you like me to write?

I have lots of ideas but I can’t do everything. I’ll share some of them so that you can discuss them:

  • New in Debian testing: a regular column covering changes affecting testing users.
  • Short presentations of software available in Debian/Ubuntu (like debaday.debian.net used to do).
  • Articles covering wishlist bugs on developers-reference so that they can be easily reused to improve the documentation!
  • Interviews of Debian contributors.
  • Description of small tasks that one can do to start contributing.

Pleases discuss and share your ideas in the comments. Don’t limit yourself to the above list, you know better than me what you need: tell me what kind of documentation was lacking in your daily usage of Debian/Ubuntu, or what could have been better explained while you tried to contribute to Debian/Ubuntu.

While I set no limits on Debian/Ubuntu topics that I accept to cover, my main focus is around documentation for end-users and/or contributors.

If you prefer you can also send your feedback with Identi.ca, Twitter or leave a comment in the entry for this article in my facebook page.

Secret figures of a Debian/Ubuntu blogger: what you liked most on raphaelhertzog.com

October 25, 2010 by Raphaël Hertzog

Chart goes up on screenI launched raphaelhertzog.com this summer (taking over the English content of my former multi-lingual blog), when I decided that I would be more serious about blogging on Debian/Ubuntu related topics. On September, I decided to write 2 articles per week and up to now I managed to keep the schedule.

Two of my articles were published by Linux Weekly News, those are much more researched than the average blog article (they are tagged with [LWN] in the list below).

The most popular articles

Most people read my blog through the RSS feed which happens to be syndicated on Planet Debian and Planet Ubuntu. According to the feedburner’s statistics, the top-5 articles are:

  1. 5 reasons why I still contribute to Debian after 12 years (32700 views)
  2. [LWN] Understanding Membership Structures in Debian and Ubuntu (31700 views)
  3. Social Micropayment Can Foster Free Software, Discover Flattr (30100 views)
  4. Everything you need to know about conffiles: configuration files managed by dpkg (29900 views)
  5. How to make 110.28 EUR in one month with free software and Flattr (29400 views)

But I also have occasional readers visiting my blog because my articles are announced on Identi.ca, Twitter and Facebook (and they circulate on social networks, thanks to those who are sharing them!). The top-5 articles according to the statistics of my website are:

  1. 5 reasons why I still contribute to Debian after 12 years (6000 views)
  2. [LWN] Can Debian offer a Constantly Usable Testing distribution? (5000 views)
  3. Understanding Debian’s release process (1500 views)
  4. Flattr FOSS (1400 views, not an article but I regularly blog about this project)
  5. Can Debian achieve world domination without being on Facebook? (1100 views)

The most flattered

Since I am using Flattr on my blog, it can be interesting to see the articles which generated lots of flattr micro-donations. The top-3 articles are my articles about Flattr (1, 2, 3). Excluding articles related to Flattr, the top-5 is:

  1. 5 reasons why I still contribute to Debian after 12 years (12 flattr)
  2. The secret plan behind the “3.0 (quilt)” Debian source package format (10 flattr)
  3. How to use multiple upstream tarballs in Debian source packages? (5 flattr)
  4. [LWN] Understanding Membership Structures in Debian and Ubuntu (4 flattr)
  5. Do You Want a Free Debian Book? Read on. (4 flattr)

Most articles get 2 to 3 flattr clicks.

The most commented

I usually get 4-5 comments on most articles but some generate much more feedback:

  1. [LWN] Can Debian offer a Constantly Usable Testing distribution? (40 comments)
  2. 5 reasons why I still contribute to Debian after 12 years (22 comments)
  3. Can Debian achieve world domination without being on Facebook? (15 comments)
  4. How to generate different dependencies on Debian and Ubuntu with a common source package (14 comments)
  5. [LWN] Understanding Membership Structures in Debian and Ubuntu (12 comments)

Factoids

Here are my conclusions based on the above figures:

  • Writing about your Debian/Ubuntu work and your long term involvement makes for highly popular content that spreads well.
  • In-depth and well researched articles (like those written for LWN) do not generate more flattr revenues than the average article even if they take 4 to 8 times as long to write.
  • People are more likely to flattr you for your free software contribution than for the value they get out of your article.
  • People care a lot about the Debian release process, and like to discuss the topic.

If you also appreciate the above-linked articles, you should click here to subscribe to my email newsletter.

Understanding Debian’s release process

October 18, 2010 by Raphaël Hertzog

Currently, the main product of the Debian project is its stable release[1]. Those release come out approximately every 18-24 months. This article gives a short overview of the process leading to the next stable release.

Creating a new distribution

Immediately after a stable release, a new distribution is created in the Debian archive. Its initial content is a copy of the (just released) stable distribution. Its codename is decided by the release managers and there’s a tradition of picking a character’s name from the Toy Story movie.

As an example, the “wheezy” distribution will be created once “squeeze” (aka Debian 6.0) is out.

For simplicity there’s a generic name to refer to the distribution used to prepare the next stable release: it’s testing. In the Debian archive, testing is just a symbolic link pointing to the right directory (squeeze currently).

Updating packages, working on release goals

During most of the cycle, developers work on packaging new upstream versions and implementing release goals. They upload their packages in the unstable distribution.

From there packages trickle to the testing distribution once they satisfy some quality checks: they must not have new release-critical bugs, they must have been built on all architectures that were previously supported, they must not break any dependency in testing, and they must have spent at least 10 days in unstable.

This minimal period ensures the package has been tested and gives enough time to users to file bugs if the package is suffering from problems. If the problems are deemed release-critical, they will block the migration of the package to testing.

During this part of the release cycle, the main work of the release team is ensuring that updated packages flow from unstable to testing. It can be a tricky task: package dependencies frequently tie packages together so that they can only migrate to testing together. If only one of the tied packages is not ready (for example if a new revision has been uploaded and has not spent 10 days in unstable yet), then none of them can migrate.

Stabilizing, polishing, fixing release-critical issues

The constant churn of new packages makes it very difficult to build a very polished release. That’s why, at some point, release managers freeze the testing distribution: automatic updates are stopped and they vet every single update made to testing. They have strong requirements, the goal is to only allow updates fixing release critical bugs, or those which are low-risk and bring significant value to the user experience (like new translations, updated documentation, etc.).

During freeze, some packages are also removed because the current upstream version can’t be supported for the lifetime of the stable release.

The freeze tends to slow down the pace of changes in unstable. Many maintainers opt to push new upstream versions in experimental instead so that if they need to update their packages in testing, they can still do it through unstable. This procedure is recommended by the release managers because it means that updates that they unblock have been tested as usual. It’s not the case for updates uploaded directly to testing (through testing-proposed-updates).

This behavior is rather annoying for the bleeding-edge users that use testing or unstable like a rolling release.

Release time

Once release managers are satisfied of the quality of the new distribution, some last minute work is needed, like generating the CD images. In the Debian archive, the release is made official by pointing the “stable” symbolic link to the new distribution (and the “oldstable” one to the previous distribution).

Now it’s party time, the cycle is over, and a new one can start. 🙂

[1] The Constantly Usable Testing project aims to make testing a first-class product like stable—but with a very different update policy.

Follow me on Identi.ca, Twitter and Facebook.

Correctly renaming a conffile in Debian package maintainer scripts

October 14, 2010 by Raphaël Hertzog

After having dealt with the removal of obsolete conffiles, I’ll now explain what you should do when a configuration file managed by dpkg must be renamed.

The problem

Let’s suppose that version 1.2 of the software stopped providing /etc/foo.conf. Instead it provides /etc/bar.conf because the configuration file got renamed. If you do nothing special, the new conffile will be installed with the default configuration, and the old one will stay around. Any customization made by the administrator are lost in the process (in fact they are not lost, they are still in foo.conf but they are unused).

Of course, you could do mv /etc/foo.conf /etc/bar.conf in the pre-installation script. But that’s not satisfactory: it will generate a spurious conffile prompt that the end-user will not understand.

The solution

In the preinst script, you have to verify if the old conffile has been modified by the administrator. If yes, you want to keep the file around. Otherwise you know you will be able to ditch it once the upgrade is over, and you rename it to /etc/foo.conf.dpkg-remove to remember this fact.

In the postinst script, you remove /etc/foo.conf.dpkg-remove. If the old conffile (/etc/foo.conf) still exists, it’s because it was modified by the administrator. You make a backup of the new conffile in /etc/bar.conf.dpkg-dist and rename the old one into /etc/bar.conf.

In the postrm, when called to abort an upgrade, you move /etc/foo.conf.dpkg-remove back to its original name.

In practice, use dpkg-maintscript-helper

dpkg-maintscript-helper can automate all those tasks. You just have to put the following snippet in the maintainer scripts (postinst, postrm, preinst):

if dpkg-maintscript-helper supports mv_conffile 2>/dev/null; then
    dpkg-maintscript-helper mv_conffile /etc/foo.conf /etc/bar.conf 1.1-3 -- "$@"
fi

In this example, I assumed that version 1.1-3 was the last version of the package that contained /etc/foo.conf (i.e. the last version released before 1.2-1 was packaged).

You can avoid the preliminary test if you pre-depend on “dpkg (>= 1.15.7.2)” or if enough time has passed to assume that everybody has a newer version anyway. You can learn all the details in dpkg-maintscript-helper’s manual page.

Debhelper support

Debhelper makes it easy to inject those commands in the maintainer scripts. You just have to provide debian/*.maintscript files. See dh_installdeb’s manual page for details.

Found it useful? Be sure to not miss other packaging tips (or lessons), click here to subscribe to my free newsletter and get new articles by email (just check “Send me blog updates”).

  • « Previous Page
  • 1
  • …
  • 74
  • 75
  • 76
  • 77
  • 78
  • …
  • 95
  • Next Page »

Get the Debian Handbook

Available as paperback and as ebook.
Book cover

Email newsletter

Get updates and exclusive content by email, join the Debian Supporters Guild:

Follow me

  • Email
  • Facebook
  • GitHub
  • RSS
  • Twitter

Discover my French books

Planets

  • Planet Debian

Archives

I write software, books and documentation. I'm a Debian developer since 1998 and run my own company. I want to share my passion and knowledge of the Debian ecosystem. Read More…

Tags

3.0 (quilt) Activity summary APT aptitude Blog Book Cleanup conffile Contributing CUT d-i Debconf Debian Debian France Debian Handbook Debian Live Distro Tracker dpkg dpkg-source Flattr Flattr FOSS Freexian Funding Git GNOME GSOC HOWTO Interview LTS Me Multiarch nautilus-dropbox News Packaging pkg-security Programming PTS publican python-django Reference release rolling synaptic Ubuntu WordPress

Recent Posts

  • Freexian is looking to expand its team with more Debian contributors
  • Freexian’s report about Debian Long Term Support, July 2022
  • Freexian’s report about Debian Long Term Support, June 2022
  • Freexian’s report about Debian Long Term Support, May 2022
  • Freexian’s report about Debian Long Term Support, April 2022

Copyright © 2005-2021 Raphaël Hertzog