On Wed, Oct 17, 2007 at 10:05:53AM +0200, Daniel Baumann wrote: > Justin Pryzby wrote: > > I think that should be declared, right? > > yep, sorry about that, and thanks for finding that bug. > > > Partial upgrades are > > "supposed to" be supported. At least shouldn't the it be declared as > > a conflicts? > > i think, a tighter versioned depends is enough (which i've just uploaded > yesterday evening). Are you sure?
$ sudo dpkg -i /var/cache/apt/archives/ncurses-bin_5.5-5_i386.deb dpkg - warning: downgrading ncurses-bin from 5.6+20071013-1 to 5.5-5. (Reading database ... 53959 files and directories currently installed.) Preparing to replace ncurses-bin 5.6+20071013-1 (using .../ncurses-bin_5.5-5_i386.deb) ... Unpacking replacement ncurses-bin ... Setting up ncurses-bin (5.5-5) ... $ infocmp infocmp: symbol lookup error: infocmp: undefined symbol: _nc_disable_period Something needs to prevent a stable system from upgrading libncurses before ncurses-bin. My understanding now is that the ELF NEEDED field is insufficient with the unstable libs since the symbol is now in a different lib. Changing the stable libs (eg. in etch rev 2 or such) isn't sufficient either, since (AFAIK) it's allowed to upgrade from any etch release to any lenny release (just skipping releases isn't allowed/guaranteed to be supported). I don't know if there's a nice solution. Even if you make libncurses and libtk codepend, you'd have to make sure to write libtik.so. before libncurses. Then (if they codepend) it seems like you might have a problem since you'll (for a short interval) have old libncurses with some symbol that's now in the new libtik. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
