Re: cdebconf, and a versioned dependency on debconf
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/
slangasek@ubuntu.com vorlon@debian.org
Reply to: