On Tue, Feb 17, 2009 at 05:53:50PM +0000, Struan Bartlett wrote: > Maybe this is a dumb question, but what determines whether a hook that > is dependent on two packages (in this case initramfs-tools and > e2fsprogs) should be put in one or the other? e.g. Why shouldn't it be > put in an example section in the initramfs-tools package? I'm thinking, > if the hook architecture of initramfs-tools changes in the future, > example hooks in 3rd-party packages would become out-of-date. On the > other hand, the filenames of mkfs.ext3, lvm and resize2fs might become > out-of-date, but possibly that is less likely.
initramfs-tools is the infrastructure, hooks on specific programs should be add by their respective packages aka udev,mdadm lvm2 and so on.. the reference examples section of initramfs-tools is man initramfs-tools > The other thing I'm thinking, is that not only are e2fsprogs hooks > useful, but at our organisation we also have hooks for fdisk, sfdisk and > there may be other utilities that are generally useful to have outwith > one's main system. I realise many users won't want the clutter in their > initramfs, but many users might consider it valuable to have a package > of common tools included in their initramfs's for ease-of-administration > purposes. > Reconsidering lvm specifically for a moment: the lvm binary is already > shipped inside the standard initramfs - except it's called vgchange. All > that's needed to make the lvm command line specifically available is a > single symlink. Does that really count as inhouse abuse? ;-) i appreciate your effort, but the initramfs should be for boots in the first cases other stuff should better be done after init is called. but happy to hear you like to use the initramfs-tools infrastructure. kind regards -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
