Re: [gentoo-dev] eselect-compiler updates and unmasking

[Jeremy Huddleston]

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 (eradicator@g.o).
>>
>> 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 <solar@g.o>
> Gentoo Linux
>
> --
> gentoo-dev@g.o mailing list
>

-- 
gentoo-dev@g.o mailing list