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
