On Fri, Nov 28, 2008 at 08:51:26PM -0600, Manoj Srivastava wrote:
> 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/
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com