-----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----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
