udpkg postunpack hook?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I was recently wanting to do an automated etch install where the target
system has a custom kernel installed in place of the one that
base_installer's pick_kernel() comes up with.
I'm aware that that in SVN this has been addressed, so won't be a problem
for lenny, but it occurred to me that if we had (in this case) a
pre_base_installer.d hooks directory, I'd have been able to drop a script
into there in the early_command, and have it do something disgusting, like
edit the pick_kernel function so that it returned what I want (OK, I admit
that's a nasty way of doing it, but given the lack of preseed functionality
in etch, at least it would have got the job done).
As it stands, my only option is to roll my own base_installer udeb, and use
the early_command to install that from my own repository (assuming that I
want to be able to tell people to use standard etch install media). That's
fine for anyone that already knows their way round the d-i build process,
but I'm trying to approach this from the point of view of one who sees that
d-i is doing almost everything they need, but not quite, and is a d-i newbie.
What I think I'd like to see (unless someone comes up with a better idea)
would be for udpkg to check for /var/lib/dpkg/info/$package.postunpack (or
some such) just after unpacking each udeb, and running it if it exists.
This would have allowed me to provide a script that sed's the
base-installer.postinst so that it does what I want.
Obviously, I'd then need be cautious about d-i being upgraded under my
feet, but the same goes for what might be the more proper approach of
rolling my own base-installer, and I could always write my script to throw
an error if the postinst's md5sum doesn't match what I expect.
Obviously, I can only currently justify this on the basis of something that
no longer needs to be fixed, so even that's a bit shaky, but then that's
inevitable. It's not like adding a check for a file that will never be
there in normal use going to significantly slow things down, or complicate
the code, but testing that code path adequately might be tough -- of
course, if people found it useful for prototyping new d-i features, that
would be dealt with too.
So, thoughts?
Cheers, Phil.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHIeFfYgOKS92bmRARAghwAJ98ONnaaou9YRIZOMRh2aKpmdgmTACglyW1
l3NoWPrA9Pd5ewMsbNetvH0=
=Bnb0
-----END PGP SIGNATURE-----
Reply to: