Re: how to handle partial upgrade problems?

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Andreas Beckmann writes ("how to handle partial upgrade problems?"):
> I wanted to write a long and technical email about this subject ... and
> started over, doing it this way:

Well done for this work by the way.  Now, on to the substance:

> I started looking for partial upgrade problems some time ago.
> Any *valid* mixture of packages from, for example, squeeze and wheezy
> (i.e. all (Pre-)Depends/Breaks/Conflicts are fulfilled) should be
> installable without errors, shouldn't it?

Yes, I think so.  Or at least, nearly any.  There are probably edge
cases where the maintainers might say "this situation is too complex
to represent in the dependency system, but we have added a Recommends
which you should have honoured".

> Since there are probably A LOT of these valid combinations, I've
> restricted my testing to candidates that are potentially more error
> prone: packages that ship the same filename or where a filename was
> moved from pkg1 to pkg2.
> 
> There are two common error classes:
> * pkg2 is missing a versioned Replaces: pkg1
>   this usually results in a file overwrite error
> * pkg2 is missing a versioned Breaks: pkg1
>   this results in files disappearing from pkg1 after the sequence
>   install pkg1, install pkg2, remove pkg2

Uh, are these packages in the same release ?  There should not be any
Breaks or Replaces between packages in the same release.

If they aren't, then the sequence in your second point is:

  install old pkg1
  --- new debian is released
  install new pkg2
  do not upgrade pkg1
  remove new pkg2

And yes, this leaves pkg1 missing files.  This sequence of actions is
not supported.  Ie, Don't Do That Then; I think that isn't a bug.

If you think it is a bug and want to support this sequence of user
actions then I guess the Breaks is an answer.  But this is a policy
question.

Ian.