A couple of rants about Launchpad

[Colin Watson]

On Tue, Mar 10, 2009 at 10:25:24PM +0000, David Gerard wrote:
> 2009/3/10 Colin Watson <cjwatson at ubuntu.com>:
> > On Tue, Mar 10, 2009 at 12:53:47PM +0800, Christopher Chan wrote:
> >> Ah, so the thing about 'apt-get dist-upgrade' not being supported
> 
> > ... which is not true ...
> 
> So you're speaking from the horse's mouth to declare that it is, in
> fact, a supported upgrade method?

I'm not going to engage in the journalistic practice of fishing for
soundbites; it's a shady practice that deliberately erases shades of
meaning for the sake of proving a point. I gave a full and detailed
description here:

  https://lists.ubuntu.com/archives/sounder/2009-March/011501.html

In case you missed it:

  We strongly recommend update-manager over other upgrade methods because
  update-manager allows us to insert workarounds for complex upgrade
  situations that in some cases just have no way to be expressed in the
  packages themselves (cf. the nfs-common problem that Debian had to
  release-note for Lenny; there was no way to do this correctly in the
  package, but "if nfs-common is installed, then upgrade it first" can be
  encoded into something like update-manager which was envisioned as
  executable release notes). As such, there are situations where if
  somebody files a bug saying "this upgrade doesn't work cleanly with
  apt-get [or aptitude]", we're eventually going to have to close the bug
  and say "sorry, we weren't able to make this work; you'll have to use
  update-manager instead". Furthermore, update-manager lets us fix
  problems after release, because its "executable release notes" component
  is downloaded on the fly from the archive.
  
  However, that's not the same as saying that an upgrade method is totally
  unsupported. In practice, the majority of problems people report with
  upgrades using apt-get or aptitude are in fact bugs in individual
  packages, and it's far simpler to fix them there than to fix them in
  individual packages. Developers should not be closing upgrade bugs
  simply because the upgrade was performed using apt rather than using
  update-manager (and if they do, feel free to refer them to me!), only
  because it's not actually possible or sane to fix the problem for users
  of apt.

In other words, there are situations where we cannot "support" upgrades
with apt-get to the extent that we will not be able to fix all the
problems that arise with them; that's the entire reason that
update-manager has additional upgrade logic. However, this does not
translate into apt-get being an "unsupported upgrade method". You can
use it and if it breaks we will look into the problems on the same
schedule as normal bug reports (I can't speak to what happens if you
have commercial support for Canonical; I'm not involved in that
operation). In some cases we may have to tell you: "sorry, this case
can't be fixed for users of apt-get, and will only work if either (a)
you do some extra manual work or (b) you use update-manager". We will
try to keep those cases to a reasonable minimum but cannot erase them
entirely. People who are comfortable with the extra manual work involved
may not regard this as a problem.

Does that answer your question? If not, what exact properties are you
looking for? "Supported" is a uselessly vague term here.

Regards,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]