Staging area for hardy-proposed ?

[Michael Vogt]

On Wed, Jun 04, 2008 at 06:33:49PM +0200, Sebastien Bacher wrote:
> Le mercredi 04 juin 2008 à 17:28 +0200, Michael Vogt a écrit :
> > Hi,
> > 
> > I would like to discuss if we should have a staging area for
> > hardy-proposed for updates that need to go in together at the same
> > time.
[..]
> What would that bring us? Upgrades that breaks something else should use
> some Breaks information to indicate that and the upgrade tools should
> set correctly everything on hold until the situation is resolved no?
> If that's not the case right no that's bugs in the tools and we should
> look at fixing those rather no?

Sorry that I haven't written my initial mail more clearly. I wanted to
ask for discussion about the fact that sometimes stuff in
hardy-proposed can not be upgraded because dependencies are missing
(not build yet).

I'm speficially having the example of openoffice.org in mind (just
because its a complex package, not to pick on it).

In hardy we have 2.4.0. In hardy-proposed we have
2.4.1~rc2. Openoffice.org needs matching openoffice.org-l10n-en-gb (or
other languages) packages. Those match the exact version of the
openoffice.org they are build against (Depends: ooo (>= 2.4.0), ooo
(<< 2.4.0.1)) and they come from a different source package than OOo.

This means that even if they are uploaded at the same time there is a
certain chance that they enter hardy-proposed at different times. This
means that users on hardy see a upgrade in update-manager that he can
not install (grayed out) because the dependencies are not available
yet. No big deal, but a bit confusing. Depending on the situation the
"partial upgrade" feature kicks in that may remove packages.

For a user who upgrades at this time from gutsy to hardy with
gutsy-proposed enabled the situation is different. The
release-upgrader tries to upgrade everything and discovers that it
needs to remove the openoffice.org-l10n-en-gb packages (or other
langauges) in order to upgrade openoffice.org. It will stop the
upgrade because it will refuse to remove translations by default. He
gets a message that the upgrade can not be calculated.

As a alternative we could simply make update-manager not use -proposed
during release upgrades to workaround problem (2) and disable the
"partial upgrades" feature in update-manager that kicks in when the
apt resolver discovers that it needs to remove packages in order to
calculate a upgrade. so that problems in part (1) go away.

My feeling is that with automatic tools the manual overhead shouldn't
be that big.

Cheers,
 Michael