Steve Langasek <[EMAIL PROTECTED]> writes:
> To date, I have not been aware of a scenario in which debconf would have
> been broken and unusable in the middle of an upgrade as a result of
> being unpacked but not yet configured; but the number of packages that
> would be rendered virtually-essential by libc6 depending on debconf is
> significant -- debconf-english, debconf-i18n, liblocale-gettext-perl,
> libtext-iconv-perl, libtext-wrapi18n-perl, libtext-charwidth-perl would
> all have to be usable when unpacked but not configured, AFAICS, in order
> for debconf to be guaranteed-usable in unpacked-only state, and given
> that glibc needs to interact with the user in the preinst in some cases,
> this would become a case of circular pre-depends among essential
> packages. (libc6 pre-depends on debconf for preinst use; debconf
> pre-depends on debconf-i18n | debconf-english to ensure usability when
> unpacked only, by enforcing unpack ordering; several of the other
> modules depend on libc6.)
> So yes, I don't see any way around this exception for glibc. postfix
> would have no excuse, though.
Okay. From a Policy perspective, I don't really want to single out libc6
unless I have to. Would it make sense to have a blanket exception for all
Essential packages, something like:
As an exception, essential packages may fall back on non-debconf
prompting if debconf is not available.
Or do we want to go a step farther and say that they can unconditionally
use non-debconf prompting?
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
