On Wed, 28 Sep 2005 00:15:24 -0700, Ryan Murray <[EMAIL PROTECTED]> said:
> On Wed, Sep 28, 2005 at 12:48:13AM -0500, Manoj Srivastava wrote:
>> Sounds to me that the package in question is getting ahead of
>> policy and deciding that the debconf transition is over. Well, is
>> it just powerpc debian installer that build depends on
>> kernel-images? Why? I am not sure that merely making this go over
>> to debconf is going to change the behaviour -- if a human does not
>> answer some install time questions, kernel-images may not install
>> anyway.
> They'll _install_ (as far as dpkg is concerned) fine. They may not
> be in a state to be booted, but you can access all of the modules
> and binaries, which I think is what the d-i package is trying to do.
> And this particular use case is during a build in a chroot, where
> you'll never want to boot the image anyhow.
> You don't need to switch to debconf to fix this -- you just need to
> check whether or not you have a tty to actually ask the question on,
> and default to the answer that allows the package to install, tho it
> may not be bootable. You can still output warning messages to that
> effect. If it's any easier, you can also check if
> DEBIAN_FRONTEND='noninteractive'. Debconf will set this when
> questions are not to be asked, and the buildd sets it as well, so
> debconf using packages use their defaults.
Sorry. The primary use case for the kernel image is for users,
perhaps novice users, who have installed the image, and whose
machines I do not wish to render unbotable. If they use lilo, a
mis-installed kernel image may well be disastrous.
So, very likely, DEBIAN_FRONTEND='noninteractive'. would
result in a failed install --- though perhaps not for for the initrd
question, I'll need to think through the various scenarios.
The point is that correct installation shall always trump
non-interactive installs as far as kernel images are concerned; so it
is not a good idea to install kenrel images in a lights out mode.
> As for the details of why d-i needs to do this, and whether or not
> it will do so on other archs in the future, you'll have to ask the
> d-i team, as I don't know.
Well, I think they should have actually tried a build and
ensured that it actually worked; and had a dialogue earlier. I would
understand it if a change in kernel-package broke a build for some
other package; then it would indeed be RC for kernel-package. But
changing a build to something that does not work, has never worked,
and requires changes in other packages to make it work, well, is a RC
bug for the package that made the change in the build system, not in
the packages that need to be changed in order for the new build to
work.
manoj
--
You have a deep appreciation of the arts and music.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
