Re: [gentoo-dev] Pending Removal of $KV

2006-06-19 Thread Arek (James Potts)

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)?


-- mailing list

Re: [gentoo-dev] Re: using specific gcc-version in ebuild

2006-06-16 Thread Arek (James Potts)

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?).


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).

-- mailing list

Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds

2006-06-07 Thread Arek (James Potts)

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.


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.


-- mailing list