Codehelp blog

Regarding my previous post on source format 3.0, I think it came across that I was blaming lintian entirely which would be unfair.

(As a side-note, a bug in serendipity XMLRPC resulting in all entries having comments disabled has led to a welcome effect of spreading the discussion more widely than a series of comments on my own site could have achieved. I'm happy with this state of affairs, so it you want to comment, either contact me by private email or put your comments on your own blog. I won't be enabling comments any time soon.)

The extended information behind the lintian warning is one thing (I've explained my position on that to Russ privately) - my main objection is to how such a warning was pushed into lintian and the entire use 3.0 or be damned approach that seems to be being adopted.

IMHO, source format 3.0 is not good enough to be the standard dpkg source format for a simple reason: It offers nothing to well maintained packages. Not all packages need NMU's - ever. Not all packages have patches - ever. Native packages and packages with the Debian maintainer upstream gain nothing from 3.0, as far as I can see.

I have 67 source packages - after much very careful consideration, I have found that a handful of those (less than 10) actually benefit from 3.0 and the rest are all unaffected. None of the packages that I will keep on 1.0 have ever had an NMU since I've been maintainer, most are either native or entirely under my sole upstream control. I will decide whether Debian gets a .tar.gz or a .tar.bz2 and although I generally offer both for download where I can, I see no reason to adopt .tar.bz2 as my default for Debian packaging.

Adding a redundant directory and file is obnoxious. I fail to see why debian/source-format would not have been perfectly suitable. Nevertheless, I will do what is necessary to avoid 3.0 until there is a compelling technical reason to adopt it.

The imperative for those in favour of 3.0 is to convince me that there is a reason TO change, not to make it difficult for me NOT to change. I do not need any reason to avoid 3.0 other than I do not have a good enough reason to move from 1.0. Making developers feel like luddites or incompetent merely because the proponents of 3.0 have failed to convince others to move to 3.0 is just insulting. You want me to use 3.0? Explain why I should bother - the current "reasons" on the Wiki page are simply not good enough and any rehash of those will be ignored. Come up with something new or respect my decision and let me get on with more important stuff.

The new lintian addition "missing-debian-source-format" is starting to remind me of a pestering nanny.

I use source format 3.0 only where I see a technical benefit and that - so far - is restricted to packages that use a .tar.bz2 upstream and one or two with really tricky patching requirements. It is literally one or two as well - out of 67 source packages which I maintain (more than some of those nagging me to change).

Packages for which I am upstream and all my native packages will stick with source format 1.0 - because there is no technical reason to migrate. Packages where I'm not upstream but which continue to use .tar.gz and have minimal or absent patching needs will also stay with 1.0 indefinitely. (I can't see how dpkg can drop 1.0 support, even after multiple stable releases after Squeeze.)

I've no interest in being side-tracked into a pointless "discussion" with those who have already made up their minds that nobody could possibly think that 3.0 is unwelcome or uninteresting. Nagging me won't help - I don't consider 3.0 worth using and I see no technical reasons to adopt it blindly.

Crush 2.0 was abandoned last year when the freeze for Debian Squeeze was still scheduled to start at the end of 2009. Even with the expected delays in the timetable for the Debian release, there never was going to be enough time to get Crush 2.0 released with the resources available. Subsequent Crush releases have always been planned, only the release of Crush 2.0 alongside Debian 6.0 (Squeeze) was abandoned.

However, Emdebian Grip has developed nicely and Grip 2.0 is going to be a significant advance over Grip 1.0 - lots more packages, lots of bugs fixed for smoother installations, multistrap support, etc.

The success of Grip has led to a slim chance of working out something for Emdebian Crush. The current state of cross-building / multiarch in Debian means that cross-building more than a handful of packages is simply unrealistic with the resources available within Emdebian. Instead, Crush will be based on Grip for 2.0 and subsequent releases, until things settle out.

Packages that are in Grip and which are designed upstream for embedded situations will simply be made accessible in Crush without further changes. Cross-building packages like this results in binaries that are all but identical to the Grip equivalent. (There is a massive difference between adapting a package for Crush and designing the package from scratch for embedded use. Emdebian is not taking on that task.)

The changes that Crush will make are being calculated, using a shortlist of packages that are (typically) not designed for embedded use but which support a long, long string of --enable-foo options in the build system - most of which Crush can change into --disable-foo. This results in fewer dependencies for the resulting binary packages so that things like LDAP can be removed. The packages themselves are being selected on the basis of what was released in Crush 1.0 for compatibility reasons. The source packages and the resulting binary packages will be renamed (busybox-crush etc.) and suitable Provides: Replaces: and Conflicts: deployed, allowing mixing of Grip and Crush packages on one device.

Other changes are then based around replacing coreutils with a reconfigured busybox and removing perl completely. Wrapper scripts, helpers and other changes will try to stitch the gaps.

It's a chance, a bit slim but a chance nonetheless. The plan offers a possibility, a worthwhile experiment. If it works, Emdebian Crush 2.0 could be a reality on seven architectures and with 2,000 packages available, released alongside Debian 6.0 (Squeeze). If it fails, people will just have to wait for multiarch to settle out and Crush 3.0, due for release alongside Debian 7.0 (Squeeze+1). In the meantime, there's always Emdebian Grip.

I've got a few fixes to go into drivel 3.0.1 but I've been trying to decide on whether to re-factor the underlying code - libsoup specifically. Drivel has it's own way of handling xmlrpc messages and this method doesn't work well with the libsoup2.4 changes, so currently it backports some code from libsoup2.2. This isn't ideal for all the usual reasons and I've been waiting for time to sort it out.

Time is lacking. My change of career has dramatically changed the amount of time I have for upstream code and as long as drivel continues working for most people, I'm not sure how much time it deserves.

I've done a lot of refactoring in drivel already, for the GTK3 transition mainly, but this libsoup stuff is much more awkward because it raises new bugs with each blog engine that drivel tries to support. It's not helped when some blog engines retain broken XML practices that mean that the standard libsoup2.4 support simply fails to post a message with properties. (I'm looking at you livejournal.com).

Anyone fancy helping out with a branch where the old xmlrpc code can be replaced by soup_value_hash_insert? I've made an SVN branch for soup24 changes at SourceForge. There's a mailing list too (v.quiet).

I'm going to update a few screenshots, complete a few more tests and then release 3.0.1.