This post would be a sort of lookback and surprises from switching to Debian from Ubuntu.
Hi all,
One of the biggest issues which prompted my move to Debian from Ubuntu was their inability to fix bugs after stable releases. The problem usually went like this .
User: Hey this package (x) doesn’t work. Give steps to reproduce, if possible also attach a screenshot.
Developer/Maintainer (MOTU) : Could you try (x.y) from development version and see if the problem goes away.
OR
Developer/Maintainer (MOTU) : Subscribe to xyz PPA (URL for PPA)
Now both the options were crazy for me. I do not like to install a whole developmental release version just to install a latest version of a new package. When doing a dist-upgrade for that single package there used to be possibility that one would come across some other unknown bugs and unnecessary time and downtime would happen making me extremely unhappy and frustrated.
The other thing of subscribing to PPA’s in search of freshened packages would make it harder and unstable with the mixing of repositories and getting back to a clean state was next to impossible.
Enter Debian, aptitude and apt-listbugs. The last two packages saved my ass countless number of times. With Debian’s four pronged strategy of stable,testing, unstable and experimental really paid off. For the first time I could hold packages back, upgrade or downgrade a set of packages selectively, download changelogs of package versions which are say in experimental or update and I do not want to update for some reason. Even apt-show-versions is good. Packages like apt-listchanges and apt-listbugs make the environment and choices so much easier and simpler.
Some examples :-
$ apt-show-versions -a iceweasel
iceweasel 4.0.1-2 install ok installed
iceweasel 3.5.16-5 stable ftp.us.debian.org
iceweasel 3.5.18-1 testing ftp.us.debian.org
iceweasel 3.5.19-2 sid ftp.us.debian.org
iceweasel 4.0.1-2 experimental ftp.debian.org
iceweasel 5.0~a2+20110501042010-1 experimental mozilla.debian.net
iceweasel/experimental uptodate 4.0.1-2
Now I really love that sorta output as I have said before.
Rant – What is sad though if you look into the above section is that till date Debian SID/Unstable has not got iceweasel 4.0 while the mozilla.debian.net guys (who maintain the iceweasel packages in Debian) have not been able to push the packages to Sid. While its early days, its quite possible that iceweasel would again be a major point version release behind when debian hits stable. There is a good possibility of Mozilla hitting 5.0x gold (or stable) in the next 6~7 months while in Debian most probably the 4.0.x series would hit SID and then percolate down to testing and finally get into stable. Even GNOME 3.2 should be out in October/November while its going to be a hard climb to getting GNOME 3.0 into Unstable. We are right now at 26 packages out off 118 source packages just following the 3.0.x series atm 😦
Anyways, there has been lots to be positive about. For instance I have been enjoying the bandwidth saved by debian’s usage of having Diffindexes while updating the index. Something like this :-
$ sudo aptitude update
[sudo] password for shirish:
Ign http://deb.opera.com stable InRelease
Ign http://www.debian-multimedia.org sid InRelease
Hit http://deb.opera.com stable Release.gpg
Hit http://www.debian-multimedia.org sid Release.gpg
Hit http://www.debian-multimedia.org sid Release
Hit http://deb.opera.com stable Release
Hit http://www.debian-multimedia.org sid/main Sources
Hit http://www.debian-multimedia.org sid/non-free Sources
Hit http://www.debian-multimedia.org sid/main amd64 Packages/DiffIndex
Hit http://www.debian-multimedia.org sid/non-free amd64 Packages/DiffIndex
See specifically the last two lines. While I just updated this today hence no new updates otherwise you get a small diff. rather than downloading the whole package resulting in smaller bandwidth spending for both the users as well as the mirror.
Caveat: I do not know if Synaptic, Update Manager or whatever GUI interface you use whether they expose this or not. Also for a regular user I do not know whether they would care that much but some people do.
What has me particularly enthused are some of the projects in this year’s Debian GSOC . I specifically like these projects.
a. APT/Dpkg Transaction Ordering for Safety and Performance
aka “aptordering”, by Chris Baines, mentored by Michael Vogt
The ordering code in libapt is responsible for ordering the unpacking/configuration of debs so as to ensure dependencies are satisfied etc. Currently it organizes the ordering into big batches. This project further implements an ordering satisfying more constrains such as “minimal amounts of dpkg invocations”, “minimal amount of broken packages at any point”.
b. DebDelta APT Native Integration
aka “debdelta”, by Ishan Jayawardena, mentored by Michael Vogt
Improve user experience of APT and its front-ends by speeding up the upgrade process. This provides a better framework for unified handling of debdelta and future APT improvements such as parallelism. Support for stable and security upgrades as well as multiple APT related libraries is expected.
c. Dpkg Declarative Diversions
aka “declarativediversions”, by Sam Dunne, mentored by Steve Langasek
The dpkg-divert command should be replaced with a new control file with a declarative syntax which Dpkg will parse and process directly as part of the package unpack and removal phases, eliminating the problems resulting from non-atomic handling of diversions.
d. Backend Tools and Infrastructure for DEX
aka “dextools”, by Nathan Handler, mentored by Matt Zimmerman
DEX is a new program designed to help improve Debian and its derivatives by merging in changes made downstream and encouraging discussions between the various projects. As this is a new project, most of the infrastructure does not exist (or is rather hackish and incomplete). This project will create the necessary backend tools and infrastructure so that all Debian derivatives can easily make use of the DEX project.
While there are quite a few more, these four have the possibility of having the most impact from my perspective/understanding whatever. While DEX is an initiative to have patches merged in debian from ubuntu and hopefully at some point able to take patches from all debian and ubuntu-based derivatives making the debian ecosystem achieve a much higher quality and also perhaps gain few packagers and maintainers who may look for taking ownership of some package. That should make it better for Debian as well as that Debian derivative as well. Today, things are pretty much disjointed and maintaining patches, cleaning them, getting a buy-in to have the patch in upstream is a pain and a chore for smaller distributions. DEX could become a place where the DD’s know of patches (they do not have to hunt around) as well as downstream distributions and have possibility of lot of traffic and general higher quality of debian packages.
The three projects listed above and specifically the debdelta integration is something I really look forward to. If this does happen then in the near future we could have a possibility of getting true debdiffs so lot of bandwidth is actually saved for all debian-based distros which in turn may mean more mirrors, more users, more goodness all around.
The only thing I’m unsure or do not know about is whether debdiffs be advantageous when packages rebuilt for a particular version of gcc, perl, python (name your favorite part of the toolchain and/or programming language) . For e.g.
$ zcat /usr/share/doc/imagemagick/changelog.Debian.gz |less
imagemagick (8:6.6.0.4-3+b1) sid; urgency=low
* Binary-only non-maintainer upload for amd64; no source changes.
* Rebuild against perl 5.12
-- amd64 Builddd Daemon (barber) Tue, 03 May 2011 18:41:38 +0000
imagemagick (8:6.6.0.4-3) unstable; urgency=medium
As can be seen the package upgrade was nothing but a rebuild for perl 5.12 . Here the debdiff may probably turn out to be more bandwidth hungry (bigger debdiff) then actually downloading the new release. So more intelligence would be needed in dpkg and apt’s infrastructure as to which to make debdiffs and which need to have entirely new releases. The above is what is known in the debian circles as binNMU (binary non-maintainer upload). My logic may be faulty in this and would love if it turned out to be wrong.
Anyways, on a slightly different note, one of the reasons I came onto Debian unstable is while I can use newer versions of packages I am also able to give back to the community by reporting bugs and generally have a higher quality of packages. While sometimes the developers are a little bit nasty, see bug 624145 as an example. To be frank, what I resented was much the tone and what he had assumed as a developer/maintainer. Thankfully, another Debian Developer jumped to my rescue and put sanity before I responded to the same. I learnt long long time ago it’s always better to see if there are bugs which are reported which are similar or same as you and if you find somebody saying the same thing then subscribe to that bug. This of course, does not mean that I do get them all right, sometimes the wording in the bugs is too technical and while an advanced user may be saying the same thing it might not be in a way a typical user can/could understand.
Doing this, one of the things I did find frustrating though is getting an overview of the bugs I am subscribing or interested to know about in Debian. The only way is to subscribe to the bug and then any activity comes to my mail but even here things are a bit incomplete. For e.g. the same bug and one of the replies.
from Michael Biebl
to Marco d’Itri
cc 624145@bugs.debian.org,
shirish शिरीष
date Fri, Apr 29, 2011 at 22:27
subject Re: Bug#624145: udev:get warnings and errors with udev 168-1
Hi Marco
Am 29.04.2011 18:35, schrieb Marco d’Itri:
> On Apr 29, Michael Biebl wrote:
>
>> there are some valid issues in this bug report, which you seem to have missed,
> I have not missed them and even explained in another bug that the error
> messages are only cosmetic
Do you have a bug number, I couldn’t find one.
Why is that a cosmetic issue? A failing udev rule due to missing probers
in the initramfs looks like a valid bug bug to me and Kay seems to
agree. Could you elaborate please?
I think udev should either install those probers into the initramfs or
remove the calls to those probers from the rules that are installed into
initramfs.
Michael
—
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Now while everything is good, I would have liked it much better if there was also something like what launchpad does. Have a line like this at the end of the message.
See the whole-bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624145
This would make me be on top of things a bit more. In my wanderings for a tool which can do what I like I came across the debian-bts applet. While I did file few bugs as the tool is really nice, came to know later that upstream development has been discontinued. I did try another one called debgtd but that one did not work in my case. Then I was told about a program called sd . I saw the package and was turned off by the huge number of perl developmental library packages I would have to install in order to compile it and the upstream webpage has no proper documentation of which libraries or/and packages are needed nor screenshots of the package itself.
At the end it’s just debian-bts-applet which would serve me for another 6 months or so till GNOME 3 does not come into unstable. Once that comes in though then do not think that the applet would work anymore 😦
On a more positive note, came to know possibility of three new debian packagers and contributors coming up in my city. I do long to see the day where there are more debian contributors, more debian maintainers and developers from India which would make the Debian ecosystem much more healthy and probably more tooled for our use.
That’s all for now.
Experiences in the community 