Re: initrd/initramfs: we discussed enough, let's take some action now :)

[Sven Luther <sven.luther@wanadoo.fr>]

On Wed, Oct 12, 2005 at 03:26:45PM +0900, Horms wrote:
> On Sun, Oct 09, 2005 at 02:21:04PM +0200, Sven Luther wrote:
> > On Sun, Oct 09, 2005 at 02:15:18PM +0200, Sven Luther wrote:
> > > Hi all,
> > > 
> > > Ok, now that linux-2.6.13-1 has been uploaded to experimental, and despite the
> > > abysmal situation of the experimental autobuilders and ways to grab logs,
> > > it is time to finalize the story about the initrd stuff.
> 
> Hi Sven,
> 
> your proposal regarding updating initrd-tools, initramfs-tools and yaird
> to allow them to be more sensibly called sounds fine to me. I can't
> speak on behalf of their repective maintainers, nor on
> behalf of the kernel-package maintainer, but it certainly seems
> worthy of coming up with some patches to test out.

Ok, you seem to be the only one who commented positively, and nobody else
seems to care enough to comment, and i had trouble enough getting others to
even read the email through pushing them to do so on irc, so i guess as always
things end up to be decided by those who do the job.

As you said, the proposal is sensible, seems open to any future choice we
make, and nobody objected, so i will no go ahead with the next step.

I have already modified linux-2.6/debian/templates/control.image.in to show :

  Depends: initramfs-tools | yaird | linux-ramdisk-tool, module-init-tools (>= 0.9.13)

I dropped the initrd-tools conflict, and ideally initramfs-tools and yaird
should be listed with a versioned dependency on the version which first
implements the --supported-host-version and --supported-target-version
options, and preferably initramfs-tools should be dropped from the arches
which have problems with it right now, or better yet we put yaird first until
the initramfs-tools/klibc is build-clean.

Anyway, next step starting now is :

  fill an RC bug report against initramfs-tools, yaird and initrd-tools,
  asking for :

    1) addition of a Provides: linux-ramdisk-tool.

    2) supporting the --supported-(host|target)-version calls.

Once that is done, the third step in the support migration will be
kernel-package, but this may well be for next week, we will see how reactive
the ramdisk-tool folk are :)

Friendly,

Sven Luther