On Saturday 11 February 2006 02:52, Ron Bickers <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-user] GnuPG depends on gentoo-sources?': > # emerge -pvt =app-crypt/gnupg-1.4.2-r3 > > These are the packages that I would merge, in reverse order: > > Calculating dependencies ...done! > [ebuild R ] app-crypt/gnupg-1.4.2-r3 -X +bzip2 -caps +curl -ecc > -idea +ldap +nls +readline (-selinux) -smartcard -static -usb +zlib 0 kB > [ebuild N ] sys-kernel/gentoo-sources-2.6.15-r1 -build -doc > -symlink (-ultra1) 0 kB
Huh. Weird, it's not listed in the ebuild. Oh, I found it, it was added in one of the inherited eclasses. :/ You can use /etc/portage/package.provided (IIRC) to tell gentoo you will provide this package, rather than have portage install it. You may need to specify the virtual package (virtual/linux-sources) and not the actual package portage is trying to use, but I'm not sure... > There is a note in the gnupg ebuild that points to a bug talking about > the need for (or not) kernel sources. I didn't quite follow the > arguments and solution, but it had something to do with installing gpg > suid root. At any rate, it doesn't make sense (to me) for gnupg to > require kernel sources to build or install. Well, I /sort of/ understand what is going on in the mind of the ebuild maintainer. The suid bit is only required for kernel versions less than 2.6.9, and the maintainer wants to avoid (for security reasons, I suppose) setting the suid bit for kernels at or above this version. Now, instead of using parsing uname and and getting the version of the *running* kernel, the ebuild checks files in the current /usr/src/linux directory/symlink to determine what version to build against. Either approach seems acceptable, but flawed in some way. Using /usr/src/linux causes problems for you and may yield a gnupg that doesn't work (or at least, doesn't get the protected memory features) in the running kernel; using uname may be a security risk (to what degree is a matter of opinion) if you're in a chroot or otherwise preparing a gentoo system but not running within it. Of course, this means that the package.provided method probably won't work since it won't actually provide a /usr/src/linux directory/symlink with the right files. :/ It only seems to affect the suid bit, and gnupg is one of those applications that you can probably trust with suid permissions anyway -- if it were my ebuild, I probably would have just set the suid bit and not checked the kernel version at all, but maybe that's why I'm not an ebuild maintainer. There is a bugfix for 113474 in my version (--sync'd today) that says it removes the requirement for a compiled kernel, but I don't see it removing the dependency so I'd wager that bug might not actually be fixed. :P It might allow you to use the package.provided technique though. Rechecking the eclass makes me fairly sure you can use package.provided, but that could cause problems down the road -- nevertheless I'd try it if I were you. If package.provides doesn't work, I think your best bet at this point might actually be getting hold of the ebuild maintainer or another gentoo dev and trying to convince them to drop the dependency. That may not be the easiest task though, since the DEPEND is needed, at least the way I read the ebuild. You can also use an overlay with the "extra" dependency factored out in the meantime. Sorry I couldn't be of more help. -- Boyd Stephen Smith Jr. [EMAIL PROTECTED] ICQ: 514984 YM/AIM: DaTwinkDaddy -- gentoo-user@gentoo.org mailing list
