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] Re: using specific gcc-version in ebuild
Sven Köhler wrote: some software, like qemu and others, are simply not compatible with gcc 4.x and they will not become compatible due to severe conceptional issues. then they stay broken ... add a warning to the ebuild if `gcc-major-version` is 4 (see toolchain-funcs.eclass) Hmm, but ... there is the possibility to have multiple gcc versions installed. So why not set CC and/or CXX variables inside the ebuild, and then compile the app with the right gcc-version? At this point, it just bugs me, that gentoo is staying below its potential. Well, hmmm, you might want to say, that there will be trouble because of applications/libraries linked to different libstdc++ versions - or something else. I'm always willing to learn, but this really bugs me, because gentoo really has potential for what's needed in this situation. Well, the problem here is that compiling some packages with one version of GCC and others with another version of GCC (on the same system) is asking for trouble. This means that ebuilds shouldn't change the GCC version in use. If the user wants to try it and see if it works, let them have at it, but don't do it automatically - it *will* eventually break someone's system (maybe not with 3.4+4.0/4.1, but who knows with future versions...remember the migration from GCC 3.3 to 3.4?). --Arek P.S. Who knows...eventually these incompatible packages might just make the move to GCC 4 (possibly on a major update). Until they do, tho, they'll just have to be broken (which is a shame...I like qemu). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
Donnie Berkholz wrote: Jakub Moc wrote: =virtual/x11-7 is hiding breakage in ebuilds that are not ported for modular X. I couldn't agree more, but I was forced to add this rather than allow unported ebuilds to break. Thanks, Donnie Hmmm...Looks to me like it would be a great idea to fix the unported ebuilds. Would it be possible to mark virtual/x11-7 as deprecated (using enotice/ewarn or similar), in order to get people to port any build relying on it to modular X? The way I see it, once virtual/x11-7 has been deprecated for a while (6 months to a year) and most popular packages have been ported to modular X, virtual/x11-7 and any packages still relying on it could be given Last Rites. --Arek -- gentoo-dev@gentoo.org mailing list
