Assesment [LWN.net]

Assesment

Posted Aug 5, 2009 20:32 UTC (Wed) by dmaxwell (guest, #14010)
In reply to: Assesment by atoponce
Parent article: Shuttleworth: On cadence and collaboration

I look at Ubuntu, and the contributions they've made to GNU/Linux, and it's impressive. However, they've also diverged so much from upstream, that it's difficult to take the Ubuntu packages and install them on a Debian system, or otherwise. It's becoming wholly Ubuntu-dependent.

Largely true but I'll note a bright spot. The way Debian source packages are handled and installed aren't very different between the two. I won't pin an Ubuntu binary package into a Debian machine or vice versa but I often build source packages from one on the other. For instance, at one point Ubuntu had the most recent release of SpamAssassin but neither Volatile or Backports had it for Stable. So I rebuilt the Ubuntu source packages for it and installed that on my stable machine. It worked a treat. All the config and init files went where they should and it basically Just Worked. Sure I could convert and build say a Fedora package but the chances of it working correctly without a lot of surgery were not good.

This basically is the same process used at backports.org to bring newer stuff to Stable in a sane fashion.

Conversely, I'll sometimes see something tasty in Sid and build it for one of my Ubuntu desktops.

It isn't too awful to do usually:

1. Put a deb-src line from the "foreign distro" into sources.list. Note well "deb-src" ONLY.

2. apt-get build-dep package_of_interest.

The things you need to build the package come from your native distro and this is what will keep what you're building from pulling in uptizillion foreign libs and doing things like replacing your libc. If this fails then you'll need to apt-get build-dep additional-dependency and the apt-get source additional-dependency and build and install it first. I don't bother if this part starts getting ridiculous. Building something from say Jaunty on a Stable that is two years old increases the chance of excessive pain at this point. If your porting from a current Sid to Jaunty as of today then you'll probably have everything you need in your own binary depos.

3. apt-get source package_of_interest
4. cd package_of_interest_source_dir
5. fakeroot dpkg-buildpackage -b

If all goes well an installable port of the package will show up one directory upwards.

(Log in to post comments)

Assesment

Posted Aug 6, 2009 14:24 UTC (Thu) by tdwebste (guest, #18154) [Link]

I agree with everyone here, syncing up release dates doesn't do much to improve collaboration between debian and ubuntu. What is need is collaborative bug tracking and package source control.

The Ultimate Debian Database helps show ubuntu/debian package relationships.
http://udd.debian.org/
http://wiki.debian.org/UltimateDebianDatabase

Unfortunately Debian and Ubuntu use incompatible bts systems. Currently Ubuntu's launchpad based bug tracking system _bts_ is lacking accessible package version information. Bug tracking information tied to package version is essential for debian where packages go through many version iterations between releases.

This was part of the original design for Launchpad Bugs, but it never came to fruition. The very earliest bug still open on Launchpad Bugs asks for this:
https://bugs.launchpad.net/malone/+bug/424

Up to and including Hardy, ubuntu used apt-listbugs which referred to debian's bts with package version tracking. Even though this pulled bug information from the debian bts, it gave a reasonable indication of what packages contained significant bugs. apt-listbugs was withdrawn, because ubuntu package customization increasing has made the related debian bts irrelevant.

Topic branches and trees are ways by which package customization can be tracked.

In order to meet the Debian Collaboration Team's objective the launchpad bts must interface with the debian bts. Only this way developers benefit from the topic branches, trees of distributed package source control. To collabate bugs must be tracted across both debian and ubuntu and be accessable to both native debian and ubuntu developers.

Assesment

Posted Aug 6, 2009 21:57 UTC (Thu) by langagemachine (guest, #56890) [Link]

Sorry, did not follow you here (apt newbie inside) :
> The things you need to build the package come from your native distro and this is what will keep what you're building from pulling in uptizillion foreign libs and doing things like replacing your libc.

So, what will happen if the package depends on other libs, in a more recent version than installed on the system ? Will these be fetched from source, then locally installed ?