| Summary: | sys-apps/keyutils - add static use | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alon Bar-Lev (RETIRED) <alonbl> |
| Component: | New packages | Assignee: | Robin Johnson <robbat2> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | plasmaroo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
keyutils-1.0.ebuild-static.diff
keyutils-1.0-static.patch |
||
|
Description
Alon Bar-Lev (RETIRED)
2006-05-06 04:09:36 UTC
Created attachment 86251 [details, diff]
keyutils-1.0.ebuild-static.diff
An updated ebuild
Created attachment 86252 [details, diff]
keyutils-1.0-static.patch
Required patch.
No, I won't apply static to this. Compiled with '-Os -static -s', the two binaries are 500kb each (and only 50kb is saved stripping). Compiled with plain '-Os', and including the library, they are under 50k (32k stripped). There is no reason to still be building static initrd/initramfs. Use ulibc or klibc - they were designed for this purpose. I have bumped the package to 1.1. Thanks for the reply. In order to make it compiled with klibc or ulibc the ebuild should also be modifed.. right? Forcing build variables from outside of the ebuild will not remain in version bumps. Please consider adding some use flag so it will be compiled as static/klibc/ulibc for your choice. I can do this if you tell me what you prefer. Thanks! No, no ebuild modifications should be required - we've tried hard to ensure all packages in gentoo compile with multiple libc implementations as needed. Just build it in an environment where that libc is the active one. Look at the very recent genkernel-3 for ideas, or better yet, look for genkernel-4 snapshot tarballs (not sure if they are publically available yet). That's probably the best route to take. Just wondering, why do you need keyutils in your initramfs anyway? (In reply to comment #5) > No, no ebuild modifications should be required - we've tried hard to ensure all > packages in gentoo compile with multiple libc implementations as needed. Well... I always preferred the static/minimal use flags and not take snapshots like genkernel... (Haven't looked at genkernel4... Does it use the regular ebuilds?) > Just wondering, why do you need keyutils in your initramfs anyway? I've tried to work with Jari in order to make loop-aes work with this interface for disk encryption. So patch to util-linux will not be required. My current solution is specified at http://wiki.suspend2.net/EncryptedSwapAndRoot. Genkernel4 is available here: svn co https://svn.gentooexperimental.org/genkernel It's still alpha, but it resolves many of the restrictions of the old genkernel, and it's a complete rewrite). Using ebuilds imposes too many constaints on building initramfs environments. However it should be extremely trivial to add keyutils to genkernel4 (see that it supports open-iscsi already). You might also want to consider adding the keyutils functionality to busybox. (In reply to comment #7) > Genkernel4 is available here: > svn co https://svn.gentooexperimental.org/genkernel > It's still alpha, but it resolves many of the restrictions of the old > genkernel, and it's a complete rewrite). Nice work! A few requests... :) 1. Please also add --no-install-map so it will not install the kernel map as it does today. 2. Can you please consider plugin architecture for linuxrc? So components like suspend2, encrypted loops/dm-crypt etc... can be added? All it takes is to add utilities like: 1. splash-verbose 2. splash-silent 3. modprobe-group 4. rmmod-group 5. udev-refresh And call plugin in the following hooks: 1. Startup. 2. After udev. 3. Before mount root. 4. After mount root. You may also be interested in genkernel wrapper I've written http://alon.barlev.googlepages.com/genkernel-utils-0.16.tar.bz2. > You might also want to consider adding the keyutils functionality to busybox. Oh... it should be investigated! I'm not one of the genkernel4 developers - I just happen to use it as I have some strange hardware where it actually makes stuff easier. Put together a patch for skipping the kernel map and it should be accepted easily. As for the rest of your changes, I'm nowhere near familar enough with the genkernel4 codebase, but I suspect the developers would appreciate patches implementing that stuff. I've CC'd plasmaroo so you can get in touch with him about putting keyutils and your other stuff into the new genkernel. |
