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.
--Jeremy
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:
app-admin/eselect-conmpiler
sys-devel/gcc-config
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
to me ([EMAIL PROTECTED]).
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.
Thanks,
Jeremy
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
