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.
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.
If you don't care where you are, then you ain't lost.
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org