How to not collaborate with Debian (and upstream)

Lucas Nussbaum lucas at
Thu Aug 28 01:02:05 BST 2008

* If the Debian package uses a patch system, change the patch system.
  You get bonus points if you switch from dpatch to anything else,
  and rename all the patches during the process, since this increases
  the diff size significantly.

* Upstream doesn't release often enough? And marking an svn snapshot
  as such in the upstream version doesn't look good? Don't hesitate to
  make up a new upstream release (or an RC). Doesn't matter if it only
  exists in Ubuntu.

* You want to fix an upstream bug? Fix it in a way that is
  completely Debian/Ubuntu-specific (using tools like
  update-alternatives, for example). That way, upstream won't be able
  to steal your patch, and users of this software will have to switch
  to Ubuntu if they want your new feature.

* If the software is dual-licensed, license your patches under only
  one of the licenses, to make it even less likely that upstream will
  integrate them.

* When writing the changelog, make sure to forget about some changes, to
  make it less likely that the Debian maintainer will cherry-pick some
  interesting changes.

* And of course, never contact the Debian maintainer during the whole
  process, even if you find bugs in the Debian package.

Many thanks to Neil Wilson and Mathias Gug for preparing and uploading
libgems-ruby 1.3.0~RC1-0ubuntu1, ignoring my concerns raised in
LP#145267. This package provides perfect examples for each of the
above points. Nice slap in the face.
| Lucas Nussbaum
| lucas at |
| jabber: lucas at             GPG: 1024D/023B3F4F |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : 

More information about the Ubuntu-motu mailing list