On Fri, Nov 28, 2008 at 08:51:26PM -0600, Manoj Srivastava wrote: > Solutions? > a) Do not depend on cdebconf as an alternate; in which case the upgrade > works fine, but the future transition to cdebconf gets hairier. > b) depend on cdebconf, but check which variant is present, and check if > the version you are asking for has the feature present. This is > harder, more complex, and we added the versioned dependency so we do > not have to check for the rpesence of the new feature. > c) Post lenny, tell a white lie to the packaging system, and pretend > ucf breaks debconf < 1.5.19. This is not true, since it is actually > debconf that break the ucf version >= 3.005, but if the Breaks > relationship is symmetric, as implemented, this white lie would work > > c) is not possible for Lenny yet, since Etch's dpkg has no idea > what a Breaks relationship means.
> So me, I am going for option a for ucf, unless someone can point > me to a better idea. Since recent versions of cdebconf don't provide their own confmodule, but instead depend on debconf to provide it, it seems that a) is correct in and of itself: it doesn't matter if cdebconf implements the extension at the protocol level if cdebconf is server only the shell library implementing the client side of the protocol doesn't support the extension. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
