on 17/02/09 16:39 maximilian attems wrote :
On Tue, Feb 17, 2009 at 04:06:37PM +0000, Struan Bartlett wrote:
there is an open bug #378332
beware the critics of that patch and that /dev/VG/LV is *just* a
symlink. please post your patch as followup there.
Ok will try that.
cool, cursious :)
Have now done so.
that is a special case that is not worth to ship any initramfs with.
initramfs-tools is explicitly made hookable to allow such inhouse
"abuse".
I understand, that makes sense. Is there scope maybe then for a separate
package (e.g. called initramfs-tools-ext3utils) which contains and adds
in the appropriate hooks?
well doesn't make sense for a seperate package,
but you could file a whishlist bug against e2fsprogs
to shipp in it's example section or wherever this specific mkfs hook?
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.
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? ;-)
