Experiences in the community

Just another WordPress.com weblog

transitions and deferred transitions

Hi all,
This post is going to be a short one on how transitions occur in Debian as well as how sometimes the developers delay a transition for multiple reasons.

Sometime back, I had introduced the concept of transitions.

Updates,upgrades in Debian as well as other GNU/Linux distributions happen on two counts. One are upgrades as there is a new release of some package, the other is of maintenance updates to an existing package. The difference between the two is easy to know as the upgrade changes the major release version number of a Debian package while a maintenance update is simply an increment to the minor release version number . I would illustrate it with the help of the changelog of the Debian package ‘GNOME Power Manager‘ the utility/applet by which an end-user can make changes as to what happens when the concerned machine goes off mains and other power-related behaviors.

Here is the changelog/history of the changes in the gnome-power-manager package :-


gnome-power-manager (2.32.0-3) unstable; urgency=low

* debian/patches/09_Port-to-libnotify-0.7.0.patch:
Added: Port to libnotify 0.7

— Sjoerd Simons Sun, 31 Jul 2011 15:22:27 +0100

gnome-power-manager (2.32.0-2) unstable; urgency=low

* Upload to unstable.

— Michael Biebl Tue, 19 Oct 2010 23:49:34 +0200

gnome-power-manager (2.32.0-1) experimental; urgency=low

[ Josselin Mouette ]
* Move autostart file to /usr/share/gnome/autostart since Xfce now has
its own power manager. Closes: #591776.

[ Michael Biebl ]
* New upstream release.
– Port to libupower-glib. Closes: #595086
– Provide a pkexec helper for systems that do not have XRandR backlight
capability, i.e. we no longer require hal.
* debian/control.in
– Drop Build-Depends on libhal-dev.
– Change Build-Depends on libdevkit-power-gobject-dev to
libupower-glib-dev (>= 0.9.1).
– Drop Suggests: hal.
– Add Suggests: policykit-1 for pkexec.
– Bump Standards-Version to 3.9.1. No further changes.
* debian/rules
– Drop obsolete –enable-hal from DEB_CONFIGURE_EXTRA_FLAGS.

— Michael Biebl Sun, 17 Oct 2010 19:39:48 +0200

gnome-power-manager (2.30.1-1) unstable; urgency=low

* New upstream bugfix release.
* debian/rules
– Explicitly turn on hal support as the upstream default is now off.
Hal is still required for brightness control on systems that don’t
have XRandR backlight support yet. Closes: #577809
* debian/patches/09-fix-critical-warning-from-gpmscreensaver.patch
– Removed, merged upstream.

— Michael Biebl Thu, 29 Apr 2010 15:45:31 +0200

This is a good changelog to understand the different dynamics. Let’s see the changelog in a bit of detail.


gnome-power-manager (2.30.1-1) unstable; urgency=low

* New upstream bugfix release.
* debian/rules
– Explicitly turn on hal support as the upstream default is now off.
Hal is still required for brightness control on systems that don’t
have XRandR backlight support yet. Closes: #577809
* debian/patches/09-fix-critical-warning-from-gpmscreensaver.patch
– Removed, merged upstream.

— Michael Biebl Thu, 29 Apr 2010 15:45:31 +0200

Now the main thing to see remember here is the statement by the maintainer/developer stating its a ‘new upstream bugfix release’ . upstream bugfix releases are incremented in minor. See for instance this release has been numbered as 2.30.1-1 . It is the end numbers in this case the ‘.1-1’ and more explicitly the ‘.1’ tells that some changes have been done in place. Notice also at the very bottom of the changelog where a patch that Debian.org had been holding has been merged upstream so that not just debian but all free software distributions are able to profit from the patch.

The next release on 17th Oct 2010 where a new upstream release was uploaded to experimental.

gnome-power-manager (2.32.0-1) experimental; urgency=low

[ Josselin Mouette ]
* Move autostart file to /usr/share/gnome/autostart since Xfce now has
its own power manager. Closes: #591776.

[ Michael Biebl ]
* New upstream release.

Now here I have just taken a small partial snapshot of the changelog. In this above changelog, see the wordings ‘new upstream release’ . This also reflects with the major release number changing from 2.30.x series to the 2.32.x series. What the numbering is and should be is upstream’s prerogative which in this case is http://www.gnome.org/projects/gnome-power-manager/

The other interesting point in the changelog was for this release two Debian Maintainers/Developers contributed together to make the release. In Debian there are many times that a DD/DM may take partial responsibility for the changes in a package release as can be seen above.

Now this release made to the experimental channel. Now which channel to put a certain release is depended upon the Debian Maintainers/Debian Developer’s view and confidence of the changes done with a package release. If the DM/DD feel that the possibility of breakage is much more or/and they want to be more cautious they usually target the experimental channel. If they feel the changes are good enough, they will release in the unstable release directly. Sometimes they may also wait for couple of days to weeks/months till they think changes are good enough for unstable. As seen in the entry preceding that, the package did not seem to have any pre and post install bugs and hence was re-targetted to unstable by Michael Biebl.

What has been the most interesting ride so far is seeing the small and big transitions happening though. While one big one has been the systematic removal of the .la files.

The big interesting one going on right now is the transition to libnotify0.7 as can also be seen in the changelog.


gnome-power-manager (2.32.0-3) unstable; urgency=low

* debian/patches/09_Port-to-libnotify-0.7.0.patch:
Added: Port to libnotify 0.7

— Sjoerd Simons Sun, 31 Jul 2011 15:22:27 +0100

The transition to libnotify 0.7 can itself be tracked at http://release.debian.org/transitions/html/libnotify.html

That all is what made this changelog interesting. However, there are also transitions which are not talked/shared about as they are part of normal process. For instance, as part of the update/upgrade process a new version library libunique-3.0.0 has been introduced.


$ aptitude search libunique
i libunique-1.0-0 - Library for writing single instance appl
i libunique-3.0-0 - Library for writing single instance appl
p libunique-3.0-dev - Library for writing single instance appl
p libunique-3.0-doc - Library for writing single instance appl
p libunique-dev - Library for writing single instance appl
p libunique-doc - Library for writing single instance appl

Now in the above there are two different library versions given. Why didn’t they just conflict the old libunique-1.0-0 to libunique-3.0-0 ? Well, if they had done that, the gnome-desktop would have been uninstallable.

Let us what will go if I remove/purge libunique-1.0-0


$ sudo aptitude purge -s libunique-1.0-0
[sudo] password for shirish:
The following packages will be REMOVED:
libunique-1.0-0{p}
0 packages upgraded, 0 newly installed, 1 to remove and 1 not upgraded.
Need to get 0 B of archives. After unpacking 152 kB will be freed.
The following packages have unmet dependencies:
gnome-power-manager: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
libevolution: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
gnome-media: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
nautilus: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
steadyflow: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
evolution-plugins: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
evolution: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
gnome-disk-utility: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
evolution-exchange: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
empathy: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
shotwell: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
midori: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
gnome-bluetooth: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
gnome-user-share: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
gnome-control-center: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
brasero: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
totem: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
remmina: Depends: libunique-1.0-0 (>= 1.0.0) but it is not going to be installed.
The following actions will resolve these dependencies:

Remove the following packages:
1) brasero
2) empathy
3) evolution
4) evolution-exchange
5) evolution-plugins
6) gnome
7) gnome-accessibility
8) gnome-bluetooth
9) gnome-control-center
10) gnome-core
11) gnome-desktop-environment
12) gnome-disk-utility
13) gnome-media
14) gnome-power-manager
15) gnome-session
16) gnome-user-share
17) libevolution
18) midori
19) midori-dbg
20) nautilus
21) remmina
22) remmina-plugin-rdp
23) remmina-plugin-vnc
24) shotwell
25) steadyflow
26) totem
27) totem-coherence
28) totem-mozilla
29) totem-plugins

Leave the following dependencies unresolved:
30) aptoncd recommends k3b | brasero
31) capplets-data recommends gnome-control-center (>= 1:2.30.1-3)
32) evolution-common recommends evolution
33) gdm3 recommends gnome-power-manager (>= 2.28)
34) gnome-applets recommends gnome-media
35) gnome-media-common recommends gnome-media
36) gnome-panel recommends gnome-session (>= 2.26)
37) gnome-panel recommends gnome-control-center
38) gnome-screensaver recommends gnome-power-manager
39) gnome-session recommends gnome-power-manager (>= 2.28)
40) gnome-system-tools recommends gnome-control-center (>= 1:2.10.1-1)
41) mousetweaks recommends gnome-control-center
42) nautilus recommends brasero (>= 2.26)
43) nautilus-data recommends nautilus
44) network-manager-gnome recommends gnome-bluetooth

Accept this solution? [Y/n/q/?] q
Abandoning all efforts to resolve these dependencies.
Abort.

Wow, as can be seen there are quite a few packages which still depend on the library libunique-1.0-0 so taking it out will not be good, (unless I take all the package versions from experimental which do not depend upon libunique-1.0-0). There might be a few more as I have not asked the system as to how many reverse package dependencies there are. The above just showed me the packages which I had explicitly installed in my machine rather than those which are in the package archive who might be depending on this library.

It is due to the above way that two libraries which perform same function can exist and do not occupy the same address space. Of course once all the new updated/upgraded packages are in unstable which will use libunique-3.0-0 then there will be a further update of the library which will trigger the conflict version with the newer version removing the old version.

While playing/seeing this I also chanced upon deferred file updates as well. These can be seen on http://ftp-master.debian.org/deferred.html and the reasons they were put on deferred list can be seen in the respective bug numbers given against each of those file updates. Most of the time they are BinNMU (binary non-maintainer uploads) which fix some small thing which the maintainer may not know the best way to fix stuff or have time .

Anyway, this concludes my small take on the transition tracking.

Single Post Navigation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: