vdb entries did not get adjusted for packages using subslot deps. For example: /var/db/pkg/dev-db/mariadb-10.0.21/RDEPEND:>=dev-libs/openssl-1.0.0:0/0=[abi_x86_64(-)] sys-process/procps:0/0= dev-libs/libaio:0/0= >=sys-apps/sed-4 >=sys-apps/texinfo-4.7-r1 !dev-db/mariadb-native-client[mysqlcompat] >=dev-libs/openssl-1.0.0:0/0=[abi_x86_64(-)] >=sys-libs/zlib-1.2.3:0/0=[abi_x86_64(-)] sys-libs/ncurses:5/5=[abi_x86_64(-)] >=sys-libs/readline-4.1:0/0=[abi_x86_64(-)] !dev-db/mytop >=dev-libs/libpcre-8.35:3/3= !dev-db/mysql !dev-db/mariadb-galera !dev-db/percona-server !dev-db/mysql-cluster dev-db/mysql-init-scripts virtual/perl-Getopt-Long dev-perl/TermReadKey virtual/perl-Term-ANSIColor virtual/perl-Time-HiRes This is wreaking havoc on users' systems when they go to update. Autounmask suggests allowing unstable on ncurses-5.9-r101, but not on 6.0, the dep tree explodes. I'm sure I and others will have more details to add but I wanted to get this bug open finally. Been seeing problems in #gentoo all day. Right now were are suggesting users force-rebuild all packages with a dep like sys-devel/ncurses:5 recorded in /var/db/pkg/*/*/RDEPEND, other options like a forced sed on /var/db/pkg seem a bit scary.
Created attachment 410376 [details] sed solution as a script, use at own risk The sed solution does work, although is rather dangerous as Ben mentioned. This script includes a partially tested but working sed solution.
I suppose the only safe solution is to revbump all ebuilds that ever had a slot rdep on ncurses:5 :/ Will be fun to solve especially if for some foo with slot dep on ncurses, foo-1.0 is stable and foo-1.0-r1 is unstable - and there are dependencies, profile entries etc. in the tree which refer to <foo-1.0-r1
I think this might be a PMS bug/restriction. The spec gives no guarantee for the updates/ directory to be EAPI 5, nor does it give any mechanism to specify the EAPI used for the updates. So we have to assume EAPI 0 if I am not mistaken. And that EAPI does not have any subslot support. That not only means you cant use subslots in regular slotmoves, but also that these vdb updates MUST be skipped, because the PM cannot know during the update what to do with those specs.
Possible solution here: #1 - nuke all SLOT=5 ebuilds (the -r100's) and recommit them with SLOT=5.0 #2 - revbump all ebuilds that rdepend on ncurses:5 (dropbox and whatever others) to rdepend on ncurses:5.0 #3 - drop the versioned slotmoves and do a single "slot-move ncurses 5 0" because the -r100's aren't "5" anymore this should keep them from (A) conflicting with the existing VDB entries, and (B) allow slot-move to be generic instead of tied to specific versions.
note I have not tested this, I do not know if it will help.
(In reply to Ian Stakenvicius from comment #4) i don't see how that's any different. the problem is that portage recorded a bogus subslot value into the vdb (no ncurses ebuild has ever had a "/5" subslot), so trying to move all SLOT=5 to SLOT=0 makes no difference to the /5 subslot. we already have blockers in place against conflicting ncurses slots in the ncurses ebuilds themselves. and technically speaking, a package, once installed, can be satisfied by the r100 ebuild since it installs the runtime libs.
(In reply to Julian Ospald (hasufell) from comment #3) > I think this might be a PMS bug/restriction. In the case of portage, it simply doesn't try to update the *DEPEND atoms in /var/db/pkg because it's tricky to match atoms against atoms (since atoms are intended to match packages rather than other atoms). The relevant code is here: https://gitweb.gentoo.org/proj/portage.git/tree/pym/portage/update.py?h=v2.2.20.1#n83 Note that if the slotmove atom does not specify a version, then portage will go ahead and update the *DEPEND atoms in /var/db/pkg.
(In reply to SpanKY from comment #6) PMS covers the implicit case actually: When the sub-slot part is omitted from the SLOT definition, the package is considered to have an implicit sub-slot which is equal to the regular slot and then recommends managers record that expanded implicit value: The package manager may do this by inserting the appropriate slot/sub-slot pair between the colon and equals sign when saving the package’s dependencies. The sub-slot part must not be omitted here ... seems like the slotmove operator should also have the implicit expansion in play. at any rate, we can create a ncurses-5.9-r5 that updates to EAPI=5 and sets SLOT=0/5 and then all installed packages should be happy with that setup.
(In reply to SpanKY from comment #8) > > at any rate, we can create a ncurses-5.9-r5 that updates to EAPI=5 and sets > SLOT=0/5 and then all installed packages should be happy with that setup. I just tried this and it didn't work. To be clear, here's what I tested: diff -Naur ncurses-5.9-r4.ebuild ncurses-5.9-r5.ebuild --- ncurses-5.9-r4.ebuild 2015-08-26 07:01:02.000000000 +0000 +++ ncurses-5.9-r5.ebuild 2015-08-27 00:22:52.499537311 +0000 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Id$ -EAPI="4" +EAPI="5" inherit eutils flag-o-matic toolchain-funcs multilib-minimal MY_PV=${PV:0:3} @@ -13,8 +13,8 @@ SRC_URI="mirror://gnu/ncurses/${MY_P}.tar.gz" LICENSE="MIT" -SLOT="0" -KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" +SLOT="0/5" +KEYWORDS="~alpha amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="ada +cxx debug doc gpm minimal profile static-libs tinfo trace unicode" DEPEND="gpm? ( sys-libs/gpm )"
(In reply to SpanKY from comment #8) > seems like the slotmove operator should also have the implicit expansion in > play. > Not when updates are based on EAPI 0. Then it has to ignore them. The spec doesn't say anything about which EAPI to use for updates/ folder (unlike for the profiles/ directory where it does say it). So I'm not convinced we can just assume EAPI 5 there.
(In reply to Julian Ospald (hasufell) from comment #10) profiles/eapi is set to 5, so it seems kind of clear that the root applies to profiles/updates/ too
(In reply to Anthony Basile from comment #9) hmm, also add a ncurses-5.9-r99 with SLOT=5/5 that simply depends on ncurses:0/5 into stable. existing vdb entries will pull that which will pull in ncurses-5.9-r5. for unstable users, they've already moved on to ncurses:0/6, so shouldn't impact them.
(In reply to SpanKY from comment #12) > (In reply to Anthony Basile from comment #9) > > hmm, also add a ncurses-5.9-r99 with SLOT=5/5 that simply depends on > ncurses:0/5 into stable. existing vdb entries will pull that which will > pull in ncurses-5.9-r5. for unstable users, they've already moved on to > ncurses:0/6, so shouldn't impact them. That did it. So add the -r5 in comment #9 along with -r99 which is eapi 5 with slot 5/5. The diff to -r4 is diff -Naur ncurses-5.9-r4.ebuild ncurses-5.9-r99.ebuild --- ncurses-5.9-r4.ebuild 2015-08-26 07:01:02.000000000 +0000 +++ ncurses-5.9-r99.ebuild 2015-08-27 03:53:12.150961257 +0000 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Id$ -EAPI="4" +EAPI="5" inherit eutils flag-o-matic toolchain-funcs multilib-minimal MY_PV=${PV:0:3} @@ -13,8 +13,8 @@ SRC_URI="mirror://gnu/ncurses/${MY_P}.tar.gz" LICENSE="MIT" -SLOT="0" -KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" +SLOT="5/5" +KEYWORDS="~alpha amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="ada +cxx debug doc gpm minimal profile static-libs tinfo trace unicode" DEPEND="gpm? ( sys-libs/gpm )"
(In reply to SpanKY from comment #12) > (In reply to Anthony Basile from comment #9) > > that simply depends on > ncurses:0/5 into stable. I just noticed you said to depend on ncurses:0/5. I didn't need to do that. Isn't the slot selection sufficient here?
I did this for ncurses-5.9-r99: it does nothing at all other than pull in slot 0. # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI="5" SLOT="5/5" KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="gpm tinfo unicode" DESCRIPTION="console display library" HOMEPAGE="https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/" LICENSE="metapackage" DEPEND="sys-libs/ncurses:0=[gpm?,tinfo?,unicode?]" RDEPEND="${DEPEND}" and this for -r5, i converted -r3 because that is the stable one. Likely -r4 will need to be bumped to -r6 for unstable too. $ diff -u ncurses-5.9-r3.ebuild ncurses-5.9-r5.ebuild --- ncurses-5.9-r3.ebuild 2015-08-26 15:16:17.044514105 +0800 +++ ncurses-5.9-r5.ebuild 2015-08-27 12:36:18.353966985 +0800 @@ -2,7 +2,7 @@ # Distributed under the terms of the GNU General Public License v2 # $Id$ -EAPI="4" +EAPI="5" inherit eutils flag-o-matic toolchain-funcs multilib-minimal MY_PV=${PV:0:3} @@ -13,7 +13,7 @@ SRC_URI="mirror://gnu/ncurses/${MY_P}.tar.gz" LICENSE="MIT" -SLOT="0" +SLOT="0/5" KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="ada +cxx debug doc gpm minimal profile static-libs tinfo trace unicode"
(In reply to Anthony Basile from comment #14) the point of the r99 is to bridge the gap from vdb 5/5 to the 5.9 0/5 SLOT. once ncurses-6 goes stable, we can simply delete the 5.9 r99 and 0/5 ebuilds leaving behind the r100 5/5. it being r99 and 5/5 means it can safely be removed or upgraded to the r100 5/5. it also means the lower 0/5 can continue to be revbumped.
(In reply to SpanKY from comment #16) > (In reply to Anthony Basile from comment #14) > > the point of the r99 is to bridge the gap from vdb 5/5 to the 5.9 0/5 SLOT. > once ncurses-6 goes stable, we can simply delete the 5.9 r99 and 0/5 ebuilds > leaving behind the r100 5/5. > > it being r99 and 5/5 means it can safely be removed or upgraded to the r100 > 5/5. it also means the lower 0/5 can continue to be revbumped. I got it working. My original -r99 did fix the vbd subslotting issue but it re-installed ncurses and caused massive file collision. So my -r5 from comment #13 and Jason's -r99 from comment #15 worked. I got past the issue in comment #0 and i was able to emerge both -r5 and -r99. Looks like the least painful way forward.
I think we'll need two. one for 5.9 slot 5/5 and one for 6.0 slot 5/6. These two together with the 5.9 bump to EAPI should work. they will likely need to go straight to stable to match the KEYWORDS for the real versions. $ cat ncurses-5.9-r99.ebuild # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI="5" SLOT="5/5" KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="gpm tinfo unicode" DESCRIPTION="console display library" HOMEPAGE="https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/" LICENSE="metapackage" DEPEND="~sys-libs/ncurses-5.9:0=[gpm?,tinfo?,unicode?]" RDEPEND="${DEPEND}" $ cat ncurses-6.0-r1.ebuild # Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Id$ EAPI="5" SLOT="5/6" KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" IUSE="gpm tinfo unicode" DESCRIPTION="console display library" HOMEPAGE="https://www.gnu.org/software/ncurses/ http://dickey.his.com/ncurses/" LICENSE="metapackage" DEPEND="~sys-libs/ncurses-6.0:0=[gpm?,tinfo?,unicode?]" RDEPEND="${DEPEND}"
(In reply to Anthony Basile from comment #17) i think you meant comment #9 at any rate, pushed here (to unstable): http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=125fb7a6cdcde8fb1c7dd59edf87dbf276025ef4 feel free to sanity check before pushing r5/r99 to stable. note: r3->r4 is pretty trivial and was going to happen soon anyways, so r5 to stable is not that big of a concern. (In reply to Jason Zaman from comment #18) there's no need to mess with ncurses-6. it entered the tree with an explicit subslot and did not change.
(In reply to Julian Ospald (hasufell) from comment #10) also it seems like the EAPI part is irrelevant here. as Zac pointed out: (In reply to Zac Medico from comment #7) this makes a qualified slotmove more or less useless nowadays. we should just mark the functionality in PMS as "do not use". it means that you're guaranteed to do the move on the installed package, but any package that depended on it might be orphaned. which is what happened with ncurses.
(In reply to SpanKY from comment #19) since the slotmove didn't perform useful work for some packages, a bridge ebuild for 6.0 will be needed as portage has recorded things like: >=sys-libs/ncurses-5.2:5/6= in this case, renaming 6.0 to 6.0-r1 and having the 6.0 one be the bridge would probably be best so as to not worry about r# inversion.
*** Bug 558890 has been marked as a duplicate of this bug. ***
(In reply to SpanKY from comment #11) > (In reply to Julian Ospald (hasufell) from comment #10) > > profiles/eapi is set to 5, so it seems kind of clear that the root applies > to profiles/updates/ too Not really. In addition, I think this will break the upgrade-path. If you assume EAPI 5 for updates, then what happens if someone is running these updates with a PM that has max EAPI 4 support? You can maybe do very hacky dynamic EAPI stuff for the VDB updates, but you cannot allow explicit subslots in the slotmoves. So it kind of is not clear to me at all that this is allowed.
(In reply to SpanKY from comment #19) > at any rate, pushed here (to unstable): > http://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=125fb7a6cdcde8fb1c7dd59edf87dbf276025ef4 > > feel free to sanity check before pushing r5/r99 to stable. > > note: r3->r4 is pretty trivial and was going to happen soon anyways, so r5 > to stable is not that big of a concern. This fixes it on my machines (stable everywhere) and for many users in #gentoo. Can we stabilize these? (In reply to SpanKY from comment #21) > in this case, renaming 6.0 to 6.0-r1 and having the 6.0 one be the bridge > would probably be best so as to not worry about r# inversion. Are we sure this works? having the version numbers like that would be nice yeah but will portage see the old SLOT or new SLOT in the -6.0 package?
(In reply to SpanKY from comment #19) > (In reply to Anthony Basile from comment #17) > > i think you meant comment #9 > To be clear, yes I did. > this makes a qualified slotmove more or less useless nowadays. we should > just mark the functionality in PMS as "do not use". it means that you're > guaranteed to do the move on the installed package, but any package that > depended on it might be orphaned. which is what happened with ncurses. I'm amazed this hasn't happened more often. I don't know if its appropriate for pms, but we should document this technique.
I stabilized the bridge ebuilds on all arches. It has had many hours of testing and many users in #gentoo and works on all my machines. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5b9725757eaf3b7ec32ae854151183f222ba4189 We may still need ncurses-6 to be fixed but I dont have any ~arch machines so I cant test.
(In reply to Julian Ospald (hasufell) from comment #23) > (In reply to SpanKY from comment #11) > > (In reply to Julian Ospald (hasufell) from comment #10) > > > > profiles/eapi is set to 5, so it seems kind of clear that the root applies > > to profiles/updates/ too > > Not really. As I read https://projects.gentoo.org/pms/5/pms.html#x1-350004.4, the top-level eapi file applies to the whole profiles directory: "The profiles directory may contain an eapi file. This file, if it exists, must contain a single line with the name of an EAPI. This specifies the EAPI to use when handling the profiles directory; a package manager must not attempt to use any repository whose profile directory requires an EAPI it does not support." > In addition, I think this will break the upgrade-path. If you assume EAPI 5 > for updates, then what happens if someone is running these updates with a PM > that has max EAPI 4 support? Such an upgrade path from pre-EAPI-5 package managers doesn't exist any longer since profiles/eapi was increased to 5. Which happened in March 2014.
(In reply to SpanKY from comment #6) > (In reply to Ian Stakenvicius from comment #4) > > i don't see how that's any different. the problem is that portage recorded > a bogus subslot value into the vdb (no ncurses ebuild has ever had a "/5" > subslot), so trying to move all SLOT=5 to SLOT=0 makes no difference to the > /5 subslot. > > we already have blockers in place against conflicting ncurses slots in the > ncurses ebuilds themselves. and technically speaking, a package, once > installed, can be satisfied by the r100 ebuild since it installs the runtime > libs. The problem isn't the /5 subslot, the problem is that there's another package in the tree, that blocks the SLOT=0 packages, that has a SLOT=5. Also, the slot-move did *not* rewrite 5/5= to 0/5= , it left the value completely alone. So after the slot-move is processed *DEPEND still contains 5/5 (which matches r100's SLOT=5 value).
*** Bug 558932 has been marked as a duplicate of this bug. ***
(In reply to SpanKY from comment #11) > (In reply to Julian Ospald (hasufell) from comment #10) > > profiles/eapi is set to 5, so it seems kind of clear that the root applies > to profiles/updates/ too Nope. Those eapi files apply only to particular directories, not subdirectories, and only to directories that are being used as an actual profile directory, not something special like updates.
(In reply to Ian Stakenvicius from comment #28) yes, portage *should* have rewritten it, but it did not, thus existing packages broke. that's the crux of the issue.
The 5.9-r99 ebuild needed to have the multilib flags in IUSE. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=96470175e0316e0f3402cbce5a83838461e17f75 (In reply to SpanKY from comment #21) > in this case, renaming 6.0 to 6.0-r1 and having the 6.0 one be the bridge > would probably be best so as to not worry about r# inversion. I found someone who was hitting the exact same issue in 6.0 so I added the bridging ebuild for that too. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f20b4ddc60c23a84ae918f31933d8e5f0b7d9eb
(In reply to SpanKY from comment #31) > (In reply to Ian Stakenvicius from comment #28) > > yes, portage *should* have rewritten it, but it did not, thus existing > packages broke. that's the crux of the issue. No, the crux is that you *wanted* portage to rewrite it, but didn't check the spec or test it.
(In reply to Jason Zaman from comment #32) thanks, both look fine (In reply to Ciaran McCreesh from comment #33) cut the crap -- you clearly have no idea what happened. the spec is ambiguous at best, but clearly dangerous regardless. support for versioned atoms there should be dropped since it's not safe to use in any real world circumstance (any other package depending on one being moved).
(In reply to SpanKY from comment #34) > (In reply to Ciaran McCreesh from comment #33) > > cut the crap -- you clearly have no idea what happened. I know exactly what happened. No-one thought "hey look, no-one's done this before, so I should probably take a minute to check what happens if I try it rather than just pushing it". Let's not try to pretend that this is a PM/PMS issue rather than a developer QA issue.
(In reply to Ciaran McCreesh from comment #35) you're conveniently ignoring the limitations/misbehavior PMS either allows or encourages while highlighting neither. if you aren't interested in actually helping, then you're spamming the bug and wasting everyone's time. kindly use the exit.
ncurses is fixed and pms issues have been split out into dedicated bugs to focus discussion, so nothing left here
(In reply to SpanKY from comment #37) > ncurses is fixed and pms issues have been split out into dedicated bugs to > focus discussion, so nothing left here I just synced and rebuilt world with: emerge -aNDuv world --exclude sys-libs/ncurses:5 The ncurses-5.9-r5 was build along with a few rebuild: (sys-libs/ncurses-5.9-r5:0/5::gentoo, ebuild scheduled for merge) causes rebuilds for: (sys-devel/llvm-3.5.0:0/3.5::gentoo, ebuild scheduled for merge) (app-misc/screen-4.3.1:0/0::gentoo, ebuild scheduled for merge) (app-emulation/qemu-2.3.0-r5:0/0::gentoo, ebuild scheduled for merge) Then I did emerge -aNDuv world and it still wants to pull in sys-libs/ncurses-5.9-r99 as the only package. Is this expected? What do I need it for?
(In reply to Joakim Tjernlund from comment #38) > (In reply to SpanKY from comment #37) > > ncurses is fixed and pms issues have been split out into dedicated bugs to > > focus discussion, so nothing left here > > I just synced and rebuilt world with: > emerge -aNDuv world --exclude sys-libs/ncurses:5 > The ncurses-5.9-r5 was build along with a few rebuild: > (sys-libs/ncurses-5.9-r5:0/5::gentoo, ebuild scheduled for merge) causes > rebuilds for: > (sys-devel/llvm-3.5.0:0/3.5::gentoo, ebuild scheduled for merge) > (app-misc/screen-4.3.1:0/0::gentoo, ebuild scheduled for merge) > (app-emulation/qemu-2.3.0-r5:0/0::gentoo, ebuild scheduled for merge) > > Then I did emerge -aNDuv world and it still wants to pull in > sys-libs/ncurses-5.9-r99 as the only package. > > Is this expected? What do I need it for? Same behaviour here, so I masked the entire slot 5 by my own(sys-libs/ncurses:5) and portage is quiet. So I guess, I don't need it to install.
Going forward, the only reason why you'll need ncurses:5 (after the migration from :5 to :0) is to satisfy any binary packages that need a v5 version of ncurses, after the rest of the tree and system upgrades to ncurses-6.
(In reply to Ian Stakenvicius from comment #40) > Going forward, the only reason why you'll need ncurses:5 (after the > migration from :5 to :0) is to satisfy any binary packages that need a v5 > version of ncurses, after the rest of the tree and system upgrades to > ncurses-6. I can confirm that portage also pulled ncurses:5 for no obvious reason in my system but I have no binary (I mean, precompiled) packages. alb@black:~>emerge -pcv ncurses:5 Calculating dependencies... done! sys-libs/ncurses-5.9-r99 pulled in by: app-accessibility/festival-2.1-r1 requires >=sys-libs/ncurses-5.6-r2 app-accessibility/speech-tools-2.1-r2 requires >=sys-libs/ncurses-5.6-r2 app-admin/eselect-1.4.4-r102 requires sys-libs/ncurses app-arch/dpkg-1.17.25 requires >=sys-libs/ncurses-5.2-r7 app-arch/dump-0.4.44-r1 requires sys-libs/ncurses app-editors/curses-hexedit-0.9.7 requires sys-libs/ncurses:=, sys-libs/ncurses:5/5= app-editors/gvim-7.4.769 requires >=sys-libs/ncurses-5.2-r2 app-editors/hexedit-1.2.13 requires sys-libs/ncurses app-editors/vim-7.4.769 requires >=sys-libs/ncurses-5.2-r2 app-emulation/wine-1.7.50 requires >=sys-libs/ncurses-5.2:=[abi_x86_32(-),abi_x86_64(-)], >=sys-libs/ncurses-5.2:5/5=[abi_x86_32(-),abi_x86_64(-)] app-misc/tmux-1.9a requires sys-libs/ncurses app-shells/bash-4.3_p39 requires >=sys-libs/ncurses-5.2-r2 app-shells/fish-2.1.1 requires sys-libs/ncurses app-shells/tcsh-6.18.01-r2 requires >=sys-libs/ncurses-5.1 app-shells/zsh-5.0.5 requires >=sys-libs/ncurses-5.1 app-text/hunspell-1.3.3 requires sys-libs/ncurses dev-db/unixODBC-2.3.2-r1 requires >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] dev-lang/python-2.7.9-r1 requires >=sys-libs/ncurses-5.2 dev-lang/python-3.4.1 requires >=sys-libs/ncurses-5.2 dev-libs/xmlrpc-c-1.32.05-r1 requires sys-libs/ncurses dev-util/cgdb-0.6.7 requires sys-libs/ncurses dev-util/cscope-15.8a requires >=sys-libs/ncurses-5.2 dev-util/ddd-3.3.12-r3 requires sys-libs/ncurses dev-util/dialog-1.2.20150528 requires >=sys-libs/ncurses-5.2-r5[unicode] mail-client/mutt-1.5.23-r7 requires >=sys-libs/ncurses-5.2 media-sound/playmidi-2.5-r2 requires sys-libs/ncurses media-sound/timidity++-2.14.0-r2 requires >=sys-libs/ncurses-5 net-analyzer/ifstatus-1.1.0-r1 requires >=sys-libs/ncurses-4.2 net-dialup/minicom-2.6 requires sys-libs/ncurses net-ftp/lftp-4.6.3a requires >=sys-libs/ncurses-5.1 net-ftp/ncftp-3.2.5-r3 requires sys-libs/ncurses net-misc/bfgminer-5.2.0 requires sys-libs/ncurses[unicode] net-misc/cgminer-3.3.1 requires sys-libs/ncurses net-misc/netkit-talk-0.17-r5 requires >=sys-libs/ncurses-5.2 net-misc/netkit-telnetd-0.17-r10 requires >=sys-libs/ncurses-5.2:= net-misc/ytalk-3.3.0 requires >=sys-libs/ncurses-5.2 sys-apps/less-478 requires >=sys-libs/ncurses-5.2 sys-apps/texinfo-5.2 requires >=sys-libs/ncurses-5.2-r2 sys-apps/util-linux-2.25.2-r2 requires >=sys-libs/ncurses-5.2-r2 sys-boot/grub-0.97-r14 requires >=sys-libs/ncurses-5.9-r3[abi_x86_32(-)], >=sys-libs/ncurses-5.9-r3 sys-devel/bc-1.06.95-r1 requires >=sys-libs/ncurses-5.2 sys-devel/gettext-0.19.4 requires sys-libs/ncurses sys-devel/llvm-3.5.0 requires >=sys-libs/ncurses-5.9-r3:5/5=[abi_x86_32(-),abi_x86_64(-)] sys-kernel/vanilla-sources-3.18.19 requires >=sys-libs/ncurses-5.2 sys-kernel/vanilla-sources-3.18.20 requires >=sys-libs/ncurses-5.2 sys-libs/gpm-1.20.7-r2 requires >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] sys-libs/readline-6.3_p8-r2 requires >=sys-libs/ncurses-5.9-r3[abi_x86_32(-),abi_x86_64(-)] sys-libs/slang-2.2.4-r1 requires sys-libs/ncurses sys-process/procps-3.3.9-r2 requires >=sys-libs/ncurses-5.7-r7[unicode] sys-process/psmisc-22.21-r2 requires >=sys-libs/ncurses-5.7-r7 www-client/elinks-0.12_pre6 requires >=sys-libs/ncurses-5.2 www-client/links-2.8-r1 requires >=sys-libs/ncurses-5.7-r7 x11-terms/rxvt-unicode-9.21 requires >=sys-libs/ncurses-5.7-r6 >>> No packages selected for removal by depclean Packages installed: 1717 Packages in world: 501 Packages in system: 44 Required packages: 1717 Number to remove: 0
(In reply to Alexander Bezrukov from comment #41) the whole point of this bug is that vdb entries were left behind with a dep on the :5 slot. you can either rebuild those packages or install the ncurses-5.9-r99 bridge dep.
Hmmm... not gonna re-open this bug or anything, since I'm not sure I trust my memory 100% on this, but FYI I did emerge --sync then emerge -1 =sys-kernel/aufs-sources and emerge -u1a @system. Finally, I did, emerge -1 app-emulation/wine, IIRC, and BZZT! portage auto-zapped my ncurses by upgrading just the in-slot version, leaving me with only the preserved-libs, presumably due to this dep of wine: ncurses? ( >=sys-libs/ncurses-5.2:=[${MULTILIB_USEDEP}] ) And, hey, turns out ncurses fails building non-best multilib ABI's if /usr/bin/tic is missing... some uncomfortable moments, there. I'm afraid I lost scrollback and my emerge.log is straight-up incomprehensible due to parallel emerges... so, I can't say absolutely for sure what I did to cause this (but I think it was roughly as above) But, whatever I did, for sure, portage zapped my ncurses down to just preserved libs and nothing else, without any --nodeps invocation.
(In reply to Gregory Turner from comment #43) this bug has nothing to do with /usr/bin/tic. most likely you need to sync and try again. any further queries should be directed to the ones on topic like bug 558622.
(In reply to SpanKY from comment #44) > (In reply to Gregory Turner from comment #43) > > this bug has nothing to do with /usr/bin/tic. In this case, tic was mentioned just as an example, contingent to an underlying problem, namely that "emerge wine" somehow triggered a rebuild of sys-devel/ncurses:5/6, without replacing it with sys-devel/ncurses:0. This resulted in the removal of not only tic, but toe, tput, clear, reset, ncurses*-config, /etc/terminfo, /usr/share/terminfo, /usr/include/ncurses{t,w,tw}/, /usr/include/{n,}curses.h, and the rest of it. The reason I thought it might be appropriate in this bug was Jason's mention of 0f20b4d in Comment 32, ACK'ed by you in Comment 34. My impression was that the intent of 0f20b4d was to prevent just the kind of thing that happened to me. If that's right, I thought you and Jason might like to know that there's probably still some kind of issue lurking there. In other words, it seems that, after someone gets their vdb messed up, the dependency chain you've set up between :5/6 and :0/6 is not achieving quite what you want it to. I can only presume the vdb snafu itself is semantically involved, somehow, since, otherwise, I would have expected wine's >=sys-libs/ncurses-5.2:=[${MULTILIB_USEDEP}] dep to select =sys-libs/ncurses-6.0-r1:0. (or, maybe it tried to, but portage couldn't resolve the reverse dependencies or something like that... I'm not trying to diagnose this, just to communicate what happened).
(In reply to Alexander Bezrukov from comment #41) > (In reply to Ian Stakenvicius from comment #40) > > Going forward, the only reason why you'll need ncurses:5 (after the > > migration from :5 to :0) is to satisfy any binary packages that need a v5 > > version of ncurses, after the rest of the tree and system upgrades to > > ncurses-6. > > I can confirm that portage also pulled ncurses:5 for no obvious reason in my > system but I have no binary (I mean, precompiled) packages. > > alb@black:~>emerge -pcv ncurses:5 > > Calculating dependencies... done! > sys-libs/ncurses-5.9-r99 pulled in by: > app-accessibility/festival-2.1-r1 requires >=sys-libs/ncurses-5.6-r2 > app-accessibility/speech-tools-2.1-r2 requires >=sys-libs/ncurses-5.6-r2 > app-admin/eselect-1.4.4-r102 requires sys-libs/ncurses > app-arch/dpkg-1.17.25 requires >=sys-libs/ncurses-5.2-r7 Are you on stable? -5.9-r99 is the highest stable version so portage will want to install that and that package will pull in the highest SLOT=0 version (-5.9-r5) so its all fine. You will have a "useless" package installed but that cant be helped for now. When ncurses-6 gets stabilized it will all go away so it doesn't matter. (In reply to Joakim Tjernlund from comment #38) > (In reply to SpanKY from comment #37) > > ncurses is fixed and pms issues have been split out into dedicated bugs to > > focus discussion, so nothing left here > > I just synced and rebuilt world with: > emerge -aNDuv world --exclude sys-libs/ncurses:5 > The ncurses-5.9-r5 was build along with a few rebuild: > (sys-libs/ncurses-5.9-r5:0/5::gentoo, ebuild scheduled for merge) causes > rebuilds for: > (sys-devel/llvm-3.5.0:0/3.5::gentoo, ebuild scheduled for merge) > (app-misc/screen-4.3.1:0/0::gentoo, ebuild scheduled for merge) > (app-emulation/qemu-2.3.0-r5:0/0::gentoo, ebuild scheduled for merge) > > Then I did emerge -aNDuv world and it still wants to pull in > sys-libs/ncurses-5.9-r99 as the only package. > > Is this expected? What do I need it for? Technically you should not need to rebuild things that dep on ncurses. but the slotmove failed and caused this bug. rebuilds are an unfortunate side effect of this. the files on disk are the same but portage doesnt know that.
