[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Woody to Sarge upgrade and Debian menu.

On Tue, Jan 11, 2005 at 07:29:17PM +0100, Bill Allombert wrote:
> On Tue, Jan 11, 2005 at 09:17:36AM -0800, Steve Langasek wrote:
> > Of these packages, one is essential and one is virtually essential.  The
> > other two (libgcc1 and libstdc++5) are neither; although in this case they
> > *should* work just fine in a half-configured state, that seems like a hairy
> > solution.

> For background, apparently update-menus was executable in the .deb in
> woody while it was documented otherwise...

Which suggests that past problems causing update-menu to bomb out due to
lack of libraries being configured are indeed quite rare :)

> > I had a quick look at policy's description of maintainer script behavior
> > and confirmed that a simple Conflict with the obsoleted packages from woody
> > would ensure that they would be removed while the old version of menu was
> > still in a configured state.  So as long as you don't mind conflicting with
> > obsoleted packages from woody (and this seems fine to me), this is a viable
> > option.

> > What solution do you plan to use for handling broken woody prerms of
> > packages that *aren't* obsoleted in sarge?  Versioned << Confilcts are
> > discouraged in policy, because they make for messy upgrades (c.f. kde).

> What is the problem with Versioned conflicts ? By nature menu has to use
> versioned Conflicts because packages using menu do not depend on menu so
> you cannot use versionned Depends (what we want to say is 'if menu is
> installed, it should be at least version xxx').

AIUI, a versioned conflicts less-than is a problem because the packaging
tools don't resolve this to "Upgrade X first, then install Y", they resolve
it to "remove X first, then install Y".  A dist-upgrade of this sort will
succeed, but gives a suboptimal end state.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: