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. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature