Bugzilla Bug 143697

Eradictor is missing and bugs from 3 months ago are still pending resolution,
afaik about half of toolchain hates this package and some archs have already
masked it.

Therefore qa moves to mask this pending resolution of two aspects, one is that
the open bugs should be resolved, and two, that the maintainers of
eselect-compiler gain more support from within the toolchain team; putting it
in that herd doesn't do much when the herd's maintainers utterly refuse to work
on the package.

Currently the only maintainer is Jeremy, who we haven't heard from since he
blipped back onto our screens a few months back.  I've stuck my nose in a
couple of times, nothing beyond that.

That said, if toolchain agree, I'll take on maintainership/development in
Jeremy's absence; something I haven't been prepared to do before without a
multilib system, but that changed recently so I'm now prepared to do so.

With regard to outstanding bugs and an immediate way forward, I suggest that
instead of eselect-compiler replacing gcc-config(-1) outright, they both
proceed as alternatives.  That way, until the bugs are fixed in
eselect-compiler users who are affected can switch back to gcc-config.

As I see it this means:
1) Absorbing the gcc-config compatibility wrapper for eselect-compiler into
eselect-compiler itself (necessary to support those pieces of the tree that
don't have eselect-compiler support)
2) Removing sys-devel/gcc-config-2.0.0_rc1
3) Make gcc-config and eselect-compiler block each other

Here I'm assuming that some want gcc-config-1 and others want eselect-compiler,
and that gcc-config is going to proceed on its own way.

either we need to come up with a new one written by the current toolchain
maintainers, or this one needs to be split off as you've suggested (removing
gcc-config-2)

I'm a bit curious, but what problems about gcc-config-1.x does eselect-compiler
address that can't be fixed in gcc-config-1.x itself?  Rather than focus energy
into writing an entirely separate application, why not just use the less
complete tool (eselect-compiler) to address the problems that may exist in the
more common/more-complete tool (gcc-config)?

It's also been highlighted by the people behind the core eselect project that
eselect-compiler is not endorsed by them in any way, so this also makes me
wonder whether a name change should be considered, or whether eselect-compiler
be modified in such a way as to satisfy the concerns of the people behind
eselect itself.

Oh, and I forgot to add, but afaik, eselect-compiler only handles/replaces
gcc-config.  What about binutils-config?

one thing at a time, binutils-config wont really be worked on until gcc-config
is sorted out

(In reply to comment #3)
> I'm a bit curious, but what problems about gcc-config-1.x does eselect-compiler
> address that can't be fixed in gcc-config-1.x itself?

Well, I guess the biggest difference between the two is that with
eselect-compiler, the specs selection is made by the compiler selection
configuration (and teh wrapper), rather than solely the user environment as it
is done with gcc-config.  It's not a case of one solution being correct and the
other being wrong.  eselect-compiler does things in a way that meets my needs,
gcc-config does it in a way that Mike is happy with; I think there's space for
both.

Other intended differences are mostly cosmetic; use of the eselect framework
and showing selected spec instead of "default" come to mind.

Obviously there are other differences that are bugs; management of ld.so.conf
being perhaps the most critical #112156, #137917).

> Rather than focus energy
> into writing an entirely separate application, why not just use the less
> complete tool (eselect-compiler) to address the problems that may exist in the
> more common/more-complete tool (gcc-config)?

eselect-compiler is already written and is not so incomplete.  It has a few
bugs outstanding, but mainly these have not been tackled because Jeremy has not
been around; I haven't been keen on stepping on his toes.

> It's also been highlighted by the people behind the core eselect project that
> eselect-compiler is not endorsed by them in any way, so this also makes me
> wonder whether a name change should be considered, or whether eselect-compiler
> be modified in such a way as to satisfy the concerns of the people behind
> eselect itself.

I'd noticed that, although I don't know why.  I suspect it is because
eselect-compiler has generated too many support queries to the eselect project,
which they obviously can't address, and they don't want the controversy
surrounding eselect-compiler to reflect on the eselect framework itself.  If
the toolchain team are happy for me to take over eselect-compiler, sorting out
any friction with the eselect project would be a priority.

apparently pmasked by solar?

Oh wow.. Lookie here a big old master tracker bug with all the
eselect-compiler/gcc-config-2 problems.

Yeah I masked it and please do not remove the masking till such time as 
these bugs are resolved properly. It's broken far to many systems and we 
waited far to long for the maintainer to fix them.

Note: this dependency situation needs to be resolved:

equery depends eselect-compiler
[ Searching for packages depending on eselect-compiler... ]
sys-libs/glibc-2.4-r3
sys-devel/gcc-3.4.5-r1
sys-devel/gcc-4.1.1

I am using the stable gcc for amd64, gcc 3.4.6-r1, but 'emerge -uDva world' is
trying to emerge eselect-compiler. Hmmm, I believe a stable package depending
on an unstable, masked package is... bad?

equery d eselect-compiler
[ Searching for packages depending on eselect-compiler... ]
sys-devel/gcc-3.4.6-r1

(In reply to comment #10)
> I am using the stable gcc for amd64, gcc 3.4.6-r1, but 'emerge -uDva world' is
> trying to emerge eselect-compiler. Hmmm, I believe a stable package depending
> on an unstable, masked package is... bad?
> 
> equery d eselect-compiler
> [ Searching for packages depending on eselect-compiler... ]
> sys-devel/gcc-3.4.6-r1
> 

It doesn't directly depend, it's an || dependency, afaik (look in the ebuild,
not equery).  afaik this is a portage bug and the portage team is already aware
of it.

ok, solar pmasked eselect-compiler, and now? let the users figure out how to
fix this? your behaviour is as bad as the state eselect-compiler is in. you are
missing a user friendly mindset, if you lack the skills to communicate this
before you break the depgraph on a lot of systems then please at least inform
userrel so they can communicate in in gwn, announce list and frontpage.

userrel, would you be so kind to send out a message through the usual channels
that due to problems with eselect-compiler it was neccessary to pmask it. the
result is that users are unable to emerge world/system anymore. users need to
deinstall eselect-compiler and (re)install gcc-config, thanks!

(In reply to comment #12)

Erm, this doesn't affect current users that have eselect-compiler already
installed in any way that would cause them more trouble than they already have
w/ the broken tool. They can either ignore the portage notice about p.masked
packages and continue using eselect-compiler, or uninstall
eselect-compiler/gcc-config-2* and downgrade to gcc-config-1 (or unmask it if
they wish to get rid of the notice)

There's no depgraph breakage (if you are referring to Bug 143908, it's been
fixed, you need to emerge --sync).

thanks for your comment.

i have a tree from 10 minutes ago, but the problem isn't solved, i still have
depgraph problems, is the problem fixed by changing package.mask?, do i need to
update portage mannualy (due to problems with depgraph this wont happen with
emerge world/system)?, deinstall eselect-compiler?, install gcc-config?, do i
need to wait longer for tree updates?, or something else?

If this problem isn't resolved automatically with a new tree then my suggestion
to communicate an instruction through the usual channels is still valid.

> 
> userrel, would you be so kind to send out a message through the usual channels
> that due to problems with eselect-compiler it was neccessary to pmask it. the
> result is that users are unable to emerge world/system anymore. users need to
> deinstall eselect-compiler and (re)install gcc-config, thanks!
> 

As it stands right now, I don't think this is userrel's job and qa@ is already
on the CC list.

"emerge --sync" some minutes before writing this message. would be nice if it
will be fixed soon. 

# emerge -pv eselect-compiler

These are the packages that would be merged, in order:

Calculating dependencies   
!!! All ebuilds that could satisfy "eselect-compiler" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/eselect-compiler-2.0.0_rc1-r6 (masked by: package.mask)
# Ned Ludd <solar/gentoo.org> (Aug 14 2006)
# This pkg breaks working systems and eradicator
# has gone MIA yet again.
# Bugs 143697, 108398, 112156, 135702, 137917,
# 138296, 139016, 139629, 143684

- app-admin/eselect-compiler-2.0.0_rc2 (masked by: package.mask)
- app-admin/eselect-compiler-2.0.0_rc2-r1 (masked by: package.mask)

For more information, see MASKED PACKAGES section in the emerge man page or 
refer to the Gentoo Handbook.

(In reply to comment #16)

http://gentoo-wiki.com/TIP_Dealing_with_masked_packages#Hard_Masked

> (In reply to comment #16)

emerge -C eselect-compiler; emerge --oneshot =gcc-config-1* (and see comments
above and Bug 143908). 

(In reply to comment #17)
> http://gentoo-wiki.com/TIP_Dealing_with_masked_packages#Hard_Masked

Please, don't recommend unmasking this broken thing to anyone.  

I've found this solution already, but for other users it would perhaps be
usefull to extend the comment Solar made with: 'Use gcc-config for now'? 

The few bugs here did not warrent masking the tool.  You really should have
emailed me about this.  The main bugs were a missing dep (which was a split off
package from a current dep and someone forgot to check the tree for problems
that would cause) and a change made to multilib.eclass by someone who didn't
understand what that change would do.  I have reversed that change.  The other
bugs were a wishlist, a currently working package that I asked to migrate to
eselect-compiler (but worked fine with the wrapper), a problem when
bootstrapping, and a problem when someone uses crossdev-arm*.  The only *real*
bug which might warrent blocking is 112156, but I don't see that as a common
issue, and it's much easier to ask users who want to do that to downgrade until
the issue is resolved than to force EVERYONE to do it when 99% of users are
fine and downgrading will cause more headaches than just leaving well enough
alone.

(In reply to comment #20)
> The few bugs here did not warrent masking the tool.  You really should have
> emailed me about this.  The main bugs were a missing dep (which was a split off
> package from a current dep and someone forgot to check the tree for problems
> that would cause) and a change made to multilib.eclass by someone who didn't
> understand what that change would do.  I have reversed that change.  The other
> bugs were a wishlist, a currently working package that I asked to migrate to
> eselect-compiler (but worked fine with the wrapper), a problem when
> bootstrapping, and a problem when someone uses crossdev-arm*.  The only *real*
> bug which might warrent blocking is 112156, but I don't see that as a common
> issue, and it's much easier to ask users who want to do that to downgrade until
> the issue is resolved than to force EVERYONE to do it when 99% of users are
> fine and downgrading will cause more headaches than just leaving well enough
> alone.
> 

I couldn't find anyone to support keeping this in the ~arch, so it was masked. 
That is really all there is to it.  When you aren't present toolchain gets all
the bugs and toolchain seems to have no love for eselect-compiler (nor the
eselect team).  You came in, wrote a program, stuffed it in everyones upgrade
path, and then left; and you expect everyone to be all lovely dovey about it? 
At least stick around to fix the bugs that you know are coming; every piece of
software will have bugs.  Or at least arrange for someone to fix them in your
absence.  Instead they sat here rotting and people got frustrated and it got
masked.

(In reply to comment #20)
> You really should have emailed me about this.

The 700 bug mails weren't enough?

eselect-compiler is dead for now