Bug#336721: Confusion regarding ramdisk Provides; is initrd-tools still supported?
On Tue, Nov 01, 2005 at 05:02:41AM +0000, Martin Michlmayr wrote:
> Package: initrd-tools
> linux-2.6 no longer allows initrd-tools for the generation of the
> initrd. It's not clear however whether this is intentional or just a
> typo. The following changelog claims that all initrd/initramfs
> generating tools are supported, so I assume this would include
Martin, why are you being so dense ? And assume that we are stupid and don't
know what we do ? Please read both the d-k archive, the two wiki pages about
this, as well as the replies i make to your emails.
initrd-tools *NEEDS* devfs, devfs is no more supported upstream since 2.6.13,
thus initrd-tools is no more supported for kernels above 2.6.12.
initrd-tools in unstable have been modified to support a
--supported-(host|target)-version option to ask the ramdisk generating tool
what version it supports.
> | linux-2.6 (2.6.13+2.6.14-rc4-0experimental.1) experimental; urgency=low
> | * Fixed control.image.in to depend on :
> | initramfs-tools | yaird | linux-ramdisk-tool
> | where linux-ramdisk-tools is the virtual package provided by all
> | initrd/initramfs generating tools.
> initramfs-tools and yaird provide 'linux-initramfs-tool' while
> initrd-tools provides 'linux-initrd-tool'. I see that the current
> linux-2.6 depends on linux-initramfs-tool, but that is not fulfiled by
> Is this a typo in the Provides of initrd-tools or will initrd-tools
> not work with 2.6.14 kernels?
What i don't get is why you don't think we know what we do and did this on
purpose, instead of dismissing this as typo. We have been working on post
2.6.12 kernels for over a month now, and we had at least 3 experimental
packages to refine this issues, and it works quite well, except for corner
cases like yours which we hope to fix soon.