Re: [gentoo-dev] Pending Removal of $KV
On Tue, 2006-07-11 at 07:24 +0900, Georgi Georgiev wrote: - 23 only make .config checks (should be non-fatal anyway) I couldn't agree more. This bites us in the ass every single release. People who make .config checks fatal should be forced to maintain mozilla-* for a month... ;] - 4 use linux-info to modify runtime behavior Hopefully, these will go away soon, too. Again, this is something that constantly bites us when it comes to releases. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Pending Removal of $KV
maillog: 09/07/2006-17:17:59(+0100): John Mylchreest types I've tried to clarify my point fairly well above, but the dependancy is fairly strict by design. What in linux-mod except for my specific example above would continue to work if there were no kernel sources present? (I do of course know the answer but its rhetorical) To that end is the reason why the dependancy still exists. That said, I'm open to persuasion. I'm having trouble putting my thoughts in order, so I'll just throw them out, hoping it would make some sense. - if linux-sources is a dependency, then the package usually would need to be rebuilt if the kernel configuration/sources change (linux-mod already faciliates that for a good reason) - even if an ebuild is being smart and is only using linux-info to throw informational messages, the sources dependency is still there - an ebuild should specify the linux-sources dependency on its own if it really needs the sources Having said that, out of the 62 packages that inherit linux-info and do not inherit linux-mod: - 23 only make .config checks (should be non-fatal anyway) - 9 install kernel modules (so they should rather inherit linux-mod) - 8 need the kernel sources to build, so they should probably inherit linux-mod as well - 6 have a DEPEND=virtual/linux-sources already - 4 use linux-info to modify runtime behavior - 2 are obsolete This is only the easily classifiable stuff, but it certainly does seem that the linux-sources dependency can be pulled out of the eclass. -- /\ Georgi Georgiev /\ You have a truly strong individuality. /\ \/[EMAIL PROTECTED]\/\/ /\ http://www.gg3.net/ /\/\ pgpd6vB3yLpHY.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner [EMAIL PROTECTED] wrote: Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) I've been after this for quite a long time (I opened a bug but cant seem to find it) as not only is it horrifically broken, it also should never have been the job of portage internals anyways. $KV is currently being exported by linux-info purely for legacy support and as such I would like to suggest that if these ebuilds inherit linux-info as well as use $KV, then it should not require any maintainer changes. Anything I can do to encourage this move please let me know, and many thanks for raising this again. Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgppBTaSFSiXx.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tue, Jun 20, 2006 at 08:49:41PM +0900, Georgi Georgiev wrote: Could upstream have handled it better? Yes, most definitely. Did they? No, not yet. We're stuck picking up the pieces. What does upstream have to do with the decision to chmod u+s,go-r /usr/bin/gpg or not? If using a kernel older than 2.6.9, and capabilities support is in the kernel, using capabilities is only way to avoid needing to grant full setuid to the binary. For kernels newer than 2.6.9, there is another API as well. By handling it better, I mean that the code should at runtime try both interfaces, rather than pick one to compile into the binary. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpjNJVZuaUar.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tuesday 20 June 2006 20:18, Robin H. Johnson wrote: By handling it better, I mean that the code should at runtime try both interfaces, rather than pick one to compile into the binary. yeah, this differentiates good packages and mediocre packages ;) -mike pgpp6T4cBLu01.pgp Description: PGP signature
[gentoo-dev] Pending Removal of $KV
Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
maillog: 19/06/2006-11:13:33(+): Alec Warner types Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. -- / Georgi Georgiev/ Don't quit now, we might just as well lock / \ [EMAIL PROTECTED]\ the door and throw away the key. \ / http://www.gg3.net/ / / -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Georgi Georgiev wrote: maillog: 19/06/2006-11:13:33(+): Alec Warner types Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. In many cases those packages are looking for a specific kernel feature to make sure support is enabled for it. You could argue that in the case where you aren't compiling against the kernel that support being enabled isn't critical, but that is a discussion you need to have with the package maintainers. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Alec Warner wrote: Georgi Georgiev wrote: maillog: 19/06/2006-11:13:33(+): Alec Warner types Portage currently exports $KV as the current kernel version. We detect this by attempting to mess around with the things in /usr/src/linux (.config, make files, etc...) This is duplicating the superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. In many cases those packages are looking for a specific kernel feature to make sure support is enabled for it. You could argue that in the case where you aren't compiling against the kernel that support being enabled isn't critical, but that is a discussion you need to have with the package maintainers. HmmmI don't know about this, since I'm jusr a user without much programming experience, and haven't developed anything that makes use of kernel features, but If they don't actually build against the kernel, couldn't/shouldn't they look at either kernel-headers or the output of `uname -r` (possibly with a way to force the feature on if the user knows it's available but the build system isn't detecting it)? --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
Arek (James Potts) wrote: If they don't actually build against the kernel, couldn't/shouldn't they look at either kernel-headers or the output of `uname -r`? Kernel headers being the virtual/linux-headers dependency that Georgi mentioned. `uname -r` works, but is annoying because you can't build for a kernel other than the one you're running. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 05:00:41PM -0700, infowolfe wrote: Kernel headers being the virtual/linux-headers dependency that Georgi mentioned. `uname -r` works, but is annoying because you can't build for a kernel other than the one you're running. Which only applies to kernel modules, not things like gnupg that don't REALLY need kernel sources in order to function. Gnupg builds it's secure memory functionality differently based on what is available from the kernel. All of the possible APIs are available in the headers, but depending on what the kernel is configured as, affects which of the APIs provide secure memory blocks. With GnuPG, it happens that on older LiveCDs, the kernel that is running from the LiveCD doesn't offer what it wants, but the one that you would be rebooting to does. Could upstream have handled it better? Yes, most definitely. Did they? No, not yet. We're stuck picking up the pieces. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpEyOqdURUEi.pgp Description: PGP signature
