I have decided to do a random audit of the getdeb service.  GetDeb is a service which provides updated packages and other packages not distributed by Ubuntu, here are my initial conclusions.

getdeb-repository itself, is a badly packaged package which fails to conform to Debian/Ubuntu policy:

• The package depends on wget and lsb-release, which are part of the Ubuntu base system;
• The package belongs to the utils section, which is inappropriate, as getdeb is not a utility;
• The control description begins with a capital letter;
• The control long description is only one sentence long;
• debian/postinst invokes wget to download the repository GPG key when it should just ship it as part of the package (meaning that it is not piuparts clean in a non-networked environment)
• debian/postinst blindly invokes sudo, even though the package manager always runs with root access – this will break if sudo is configured to prompt for password even on uid=0, or with SELinux
• debian/postrm blindly calls rm on a configuration file; this should be left up to dpkg to do.
• debian/copyright says the package is under GPLv3, but there is no data in the package that could be placed under such a license
• debian/changelog specifies the package is specifically for karmic, if it’s a generic distribution target it should be set to unstable (update: apparently this is OK in Ubuntu, but it would never fly in Debian)

getdeb packages are not dist-upgrade clean

The packages that getdeb installs do not pass dist-upgrade because they apply arbitrary modifications to the packaging which is not necessarily applied upstream.  As an example, look at this bug against audacious in Ubuntu, which results in QA problems when people upgrade to the next version.  Admittedly, this is more related to design problems in dpkg, but I submit that the packages created by GetDeb should not stray from upstream’s packaging structure.

To avoid this problem, the GetDeb team advises that you remove all GetDeb packages from your system before upgrading; however they do not provide any mechanism for doing so easily.

getdeb packages include upstream changelogs

Debian packages should never include the upstream changelog, but instead a summarized version which lists key problems solved in the new package (with links to appropriate distribution/vendor bugs).

getdeb packages do not appropriately set Origin: in the control file

Debian packages provided by getdeb do not appropriately use the XSBC-Origin field to embed vendor information in their third-party packages.  This makes it harder to identify getdeb packages on a system, as the version tag is not reliable enough.

If I am wrong about any of this, I will be happy to correct the above.  However, given these initial conclusions I think it is appropriate to not use GetDeb, and instead use the official Ubuntu backports distribution and properly vetted repositories like Medibuntu, especially given the fact that there is no mechanism to report problems in the software downloaded from GetDeb.