[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 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...

> 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').

> I think the idea of always having an executable, functional
> /usr/bin/update-menus script in place (even if it's just a shell wrapper
> that checks the executability of the real program) also has merit as a means
> of disposing of these bugs; the current policy has always seemed a little
> too easy to get wrong...

Well, I didn't design it... I am worried about changing menu maintainer 
scripts at this late stage, though, but I will certainly consider your
proposal.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 



Reply to: