On Fri, Oct 14, 2005 at 08:04:46AM +0200, Sven Luther wrote: > 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 :)
That sound fine, though I'm not sure if the RC status is neccessary. Your call. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]