On Monday, August 31, 2015 10:55:36 PM Fernando Rodriguez wrote:
> On Monday, August 31, 2015 7:20:29 PM walt wrote:
> > On Mon, 31 Aug 2015 20:33:42 -0400
> > Fernando Rodriguez <frodriguez.develo...@outlook.com> wrote:
> > 
> > > On Tuesday, September 01, 2015 12:13:25 AM Alan McKinnon wrote:
> > > > On 31/08/2015 23:13, walt wrote:  
> > > > > I ask this strange question because this (badly broken) machine
> > > > > once again flipped between 6.0 and 6.0-r1 after rsyncing this
> > > > > morning.
> > > > > 
> > > > > First, it emerged 6.0, which turned out to be almost catastrophic
> > > > > because the qmerge phase of the emerge failed (although it claimed
> > > > > success afterwards) and deleted the entire /usr/share/terminfo
> > > > > subdirectory.  That was fun, but I won't bore you with the
> > > > > details. (The ncurses-6.0 files in /lib64 are dated August 28,
> > > > > BTW.)
> > > > > 
> > > > > Right now emerge tries to install ncurses-6.0-r1 but the 32-bit
> > > > > part of the build fails because emerge never ran make in the
> > > > > work/cross/progs directory, and so the 32-bit tools didn't get
> > > > > compiled.
> > > > > 
> > > > > I hacked around this by running make in that directory manually,
> > > > > which allowed the ebuild install and ebuild package phases to
> > > > > succeed.
> > > > > 
> > > > > Now I have an ncurses-6.0-r1 binary package available but I'm too
> > > > > scared to install it because I might need to kill myself
> > > > > afterwards :/
> > > > > 
> > > > > Any suggestions before I take the plunge?  Is ncurses-6.0-r1 the
> > > > > right version as of today, Aug 31?
> > > > > 
> > > > > Thanks.
> > > > > 
> > > > > 
> > > > >   
> > > > 
> > > > 
> > > > 
> > > > This machine was entirely unaffected by all the recent ncurses
> > > > issues:
> > > > 
> > > > [I] sys-libs/ncurses
> > > >      Available versions:
> > > >      (0)    5.9-r3 (~)5.9-r4 5.9-r5(0/5) (~)6.0-r1(0/6)
> > > >      (5)    5.9-r99(5/5) (~)5.9-r101(5/5) (~)6.0(5/6)
> > > >        {ada +cxx debug doc gpm minimal profile static-libs test
> > > > threads tinfo trace unicode ABI_MIPS="n32 n64 o32" ABI_PPC="32 64"
> > > > ABI_S390="32 64" ABI_X86="32 64 x32"}
> > > >      Installed versions:  6.0-r1(12:52:29 30/08/2015)(cxx gpm
> > > > threads unicode -ada -debug -doc -minimal -profile -static-libs
> > > > -test -tinfo -trace ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64"
> > > > ABI_S390="-32 -64" ABI_X86="32 64 -x32")
> > > >      Homepage:            https://www.gnu.org/software/ncurses/
> > > > http://dickey.his.com/ncurses/
> > > >      Description:         console display library
> > > > 
> > > > So 6.0-r1 works completely relaible on at least one Gentoo machine
> > > > in this world :-)  
> > > 
> > > Hmm, I keyworded ncurses and this is what portage wants to do:
> > > 
> > > [ebuild  r  U ~] sys-libs/ncurses-6.0-r1:0/6::gentoo
> > > [5.9-r5:0/5::fernan] USE="cxx doc gpm tinfo unicode -ada -debug
> > > -minimal -profile -static-libs {- test%} -threads% -trace"
> > > ABI_X86="32 (64) -x32" 3,059 KiB [ebuild     U ~]
> > > sys-libs/ncurses-5.9-r101:5::gentoo [5.9-r99:5::gentoo] USE="gpm
> > > tinfo unicode (-ada%) (-cxx%*) (-static-libs%)" ABI_X86="32 (64) -
> > > x32" 0 KiB [ebuild  rR   ~] sys-devel/gdb-7.10::gentoo  USE="client
> > > expat python server zlib -lzma -multitarget -nls {-test} -vanilla"
> > > PYTHON_SINGLE_TARGET="python2_7 -python3_3 -python3_4"
> > > PYTHON_TARGETS="python2_7 python3_4 -python3_3" 0 KiB [ebuild  rR
> > > ] app-misc/screen-4.3.1::gentoo  USE="pam -debug -multiuser - nethack
> > > -selinux" 0 KiB [ebuild  rR    ] app-emulation/wine-1.6.2::gentoo
> > > USE="X alsa cups custom- cflags fontconfig gecko jpeg lcms ldap mp3
> > > ncurses openal opengl perl png prelink pulseaudio run-exes samba ssl
> > > threads truetype udisks v4l xcomposite xinerama xml -capi -dos
> > > -gphoto2 -gsm -gstreamer -mono -nls -odbc -opencl - osmesa -oss
> > > -realtime -scanner -selinux {-test}" ABI_X86="32 64 -x32"
> > > LINGUAS="-ar -bg -ca -cs -da -de -el -en -en_US -eo -es -fa -fi -fr
> > > -he -hi -hr -hu -it -ja -ko -lt -ml -nb_NO -nl -or -pa -pl -pt_BR
> > > -pt_PT -rm -ro -ru -sk - sl -sr_RS@cyrillic -sr_RS@latin -sv -te -th
> > > -tr -uk -wa -zh_CN -zh_TW" 0 KiB
> > > 
> > > 
> > > That looks dangerous to me because the first build will upgrade my
> > > 5.9 installation to 6.0 and the second will reinstall 5.9. 
> > 
> > That's exactly what happened to me last week and it was a disaster.
> > Don't allow that to happen.  After hours of frustration I finally
> > got 6.0-r1 installed and everything Just Works again, but 6.0 was
> > another disaster.  Do whatever you need to do to avoid 6.0.
> > 
> > > So what happens in between when I have no 5.9 installed but
> > > everything is linked against it? Won't it need bash to build the
> > > second one? What if the 2nd build fails? Will stuff linked against
> > > 5.9 work with 6.0?
> > 
> > No, but packages linked against 5.9 will continue to work if portage
> > doesn't delete the files from 5.9 (@preserved-rebuild, etc)
> 
> Of course, stupid me isn't thinking right :)
> I'm paranoid of this package because it made my system unbootable at one 
point 
> after removing the tinfo flag and libtinfo didn't get preserved but I think 
> that was because it was a rebuild. I just installed the -r101 version first.

Actually I did do that but I stopped it before the merge phase to check what 
it was installing (because I patch the ebuild so it installs tinfo along with 
a full ncurses), when I let it go through to install phase it detects 
collisions with the old version. I guess that's the slot move issue that was 
mentioned on the other thread. So I'll let portage do what it wants and we'll 
see what happens. I did the quickpkg in case it blows up.

-- 
Fernando Rodriguez

Reply via email to