On 10/20/2009 09:19 PM, Manoj Srivastava wrote:
On Sat, Oct 17 2009, Michal Suchanek wrote:
Manoj Srivastava wrote:
On Thu, Oct 15 2009, Michal Suchanek wrote:
Manoj Srivastava wrote:
The package should support that, out of the box. Even having to
specify --initrd is superfluous. There is an option for this in
kernel's .config already so kernel-package can just read the file and
act accordingly.
Which option is this? I have BLK_DEV_INITRD but I don't use any
initramfs -- so this is just support for one, but no indication that
one actually needs an initramfs.
If I have missed a means of discovering whether an initramfs is
required, I'll be happy to rectify that.
Sorry. The default is to not force the user to have to have an
initramfs at all, since that removes a bunch of headaches.
kernel-package should not force the user neither into having an
initramfs neither into not having one. If I build a kernel with
initramfs support there is high chance I really want to use that.
Not in my experience. I build all my kernels with initramfs
support enabled for historical reasons -- but never actually use
it. And, based on experience, I am not the only one doing so. Given
the _years_ or so of current behaviour, I don't think that changing the
behaviour on speculation of user needs is viable.
Actually it is. If you build a kernel with initrd support then the
kernel will boot with an initrd. You can always pass --no-initrd if
you insist on not creating an initrd and including support for it in
the kernel.
Sorry. I want _support_ for it, since one of my machines which
uses the kernel and needs an initramfs can, but the other dozen or so
machines do nothave to. This way, I get to select, target machine by
target machine, whether or not I have an initramfs.
Why? The kernel would still work with an initrd even if the initrd is not
needed.
And there is nothing stopping you from setting --no-initrd when making package for the machines that
don't need one.
Or are you manually building the initrd on the one machine that does require it?
For me the sole reason for using kernel-package initially was that it does
build the initrd for me.
You are clearly misconfiguring your kernel. You said you don'd do
kitchensink kernels yet you include initrd support even when you don't
want to use it.
Rubbish.
I can understand that if you always build your kernel this way you
want it work out of the box even if it is illogical.
It is not illogical. A failure of imagination on your part,
really.
It's still illogical. Not building the initrd automatically does more damage than building it when
it is not needed.
Also I mostly build kernels for testing kernel bugs so I just recycle
the distribution configuration to get the same configuration with a
slightly different kernel (from patched source or from later source
that allegedly contains a fix).
If you have recent initramfs-tools istaled, you should already
be getting an initramfs -- but, in any case, if you want an initramfs,
all you need for your needs is a single cp.
I have latest initramfs-tools installed and I still don't get and initramfs.
That is odd.
Is this a bug?
Well, it would have been, had the initramfs-tools maintainer
wanted to support make-kpkg kernel images. But apparently, he does not.
Well, kernel-package and initramfs-tools need to work together seamlessly to provide a feature which
I require: generating initrds for my installed kernels.
Since you clearly have no intention to make kernel-package work with initramfs-tools on your part,
and your reply above implies there is no intention on the initramfs-tools maintainer to support
kernel-package kernels I guess I can just as well revert to just installing the kernels manually.
Thanks for maintaining kernel-package so far. It has been useful for quite some time but it looks
like that time is coming to its end.
It may be still useful for people who build their kernels regularly but for the "just add this patch
to my kernel on this machine" scenario it is no longer much good.
Thanks
Michal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
