Uhm, what is this all about? If you have suggestions, make them, but don't come out of the gate in a huff talking about unsubstantiated breakage. That's about the least constructive way to get heard.

The wrapper provided in gcc-config-2.0 provides the exact same interface to the user as gcc-config-1.x, so how is that breaking expected behavior? If anything, it's providing expected behavior to users who want it and don't care about migrating over to eselect. Additionally, If you check through the ChangeLog, you'll see that I did actively worked on gcc-config-1.x last year prior to my starting eselect-compiler. That's how I came to realize its limitations and _need_ for replacement on multilib systems. A similar wrapper is needed for binutils as has been discussed multiple times on toolchain@, and at amd64 and ppc64 dev meetings on IRC.

Additionally, eselect-compiler has been discussed multiple times on the toolchain and gentoo-dev lists over the past year (main threads started 2005-08-09, 2005-09-17, 2005.10.02), and you didn't once raise an objection until now. I'd say you missed the 10 month window I gave you, but if you do have suggestions, I'd be more than happy to hear them.

Even more so, I left eselect-compiler in package.mask for a _very_ long time as I didn't have much time to devote to its development over the past school year. During that time, very few issues were raised despite it being used by many testers and developers. This past month, I worked out all but one of the known bugs (the one remaining is just specific to the wine package on amd64) and got more testers to give it a final beating before finally unmasking it. If anything, this has been an extremely conservative development process because of the nature of this package.


On Jun 6, 2006, at 04:28 , Ned Ludd wrote:

Why are you hijacking tools not written by you, declaring
them as 2.0 and breaking the expected behaviors of them?

Please don't do that ever again.

On Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote:
I finally had a few free cycles, so I fixed up the eselect-compiler
ebuild to better handle the transition from gcc-config and updated
toolchain.eclass to better work with multilib.  I've had a bunch of
help from the amd64 devs/testers/users this past week testing it out,
and I think it's ready to be removed from package.mask sometime soon
(next week).  Before that happens, I'd like to get some feedback from
a broader test base, so if you have some time and aren't using
eselect-compiler yet, I'd appreciate your testing.  All you need to
do is add the following to /etc/portage/package.unmask:


then just update gcc-config:
$ emerge -uv --oneshot sys-devel/gcc-config

gcc-config is just a wrapper which takes the same syntax as the older
gcc-configs and makes the appropriate call to eselect-compiler.

Please report any bugs you find in bugzilla and assign them directly

Also, if you've been using eselect-compiler, you may have an issue
where your profiles don't get removed from /etc/eselect/compiler when
you unmerge gcc.  This problem is fixed now for future installs, but
you'll have to manually remove the file when you unmerge any gcc that
is on your system now.


Gentoo Linux

gentoo-dev@gentoo.org mailing list

gentoo-dev@gentoo.org mailing list

Reply via email to