cdebconf, and a versioned dependency on debconf

[Manoj Srivastava <srivasta@debian.org>]

Hi,

        This is an issue that bit me recently. ucf relies heavily on
 debconf to do its job, and thus depends on it. Way back when, it was
 told to me that we arte going to move to cdebconf, which at some point
 will be the preferred way. In the meantime, to facilitate the future
 transition, we should all depend on
    debconf | cdebconf
 to make life in the future easier.

        Now, as of version 3.005, ucf started using a feaure that has
 long been a part of cdebconf, but was only ported to debconf in version
 1.5.19, so now ucf started depending on:
   debconf (>= 1.5.19) | cdebconf  
 and this is where trouble beings.

        Suppose a machine running stable has cdebconf installed. It also
 has an old version of debconf installed,  say, one that is older than
 1.5.19. Since cdebconf was installed, the dependency requirements are
 fully satisfied, so debconf was not updated.

        Now, ucf follows the instructions in debconf-devel(7) -- and
 that just uses debconf, the older version which does nothave support
 for the feature ucf needs. Boom, there goes the update.

        Now, in any situation where we have two alternatives, and have a
 versioned dependency on one of them, but do not actually control which
 of the alternatives gets used (if, say, they are drop in replacements),
 there is going to be a potential problem.

        In the specific case, debconf (>= X.Y.X) | cdebconf  is a
 upgrade bug waiting to happen if the target machine had cdebconf and an
 older version of debconf installed.

        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.

        manoj
-- 
If you don't care where you are, then you ain't lost.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C