This is a bug and a feature request. 1. Feature request first: Once the subslot rebuild is triggered it would be extremely nice to see which exactly change led to rebuild. Now we see such a rebuild: Calculating dependencies... done! [ebuild rR ] cat/user-1::bad-slot 0 kB Would be cool to see something like Calculating dependencies... done! [ebuild rR ] cat/user-1::bad-slot 0 kB [noinstall u ] cat/slotted-lib-3/3::bad-slot [3/some-old-subslot] It would make the following bug (or grievous feature) more obvious to find: 2. The bug itself: cyclic rebuilds I've created an example overlay for you: git clone git://github.com/trofi/bad-slot.git To see a loop just run the following command some times: sudo PORTDIR_OVERLAY="$(pwd)" emerge -vuD1 cat/user step 1: >>> Emerging (1 of 2) cat/slotted-lib-3 from bad-slot >>> Installing (1 of 2) cat/slotted-lib-3 >>> Emerging (2 of 2) cat/user-1 from bad-slot >>> Installing (2 of 2) cat/user-1 step 2 and upper (loops): [ebuild rR ] cat/user-1::bad-slot 0 kB >>> Emerging (1 of 1) cat/user-1 from bad-slot >>> Installing (1 of 1) cat/user-1 $ cat /var/db/pkg/cat/user-1/RDEPEND >=cat/slotted-lib-2:3/3= <cat/slotted-lib-4:3/3= Looks fine. The real bug was observed on haskell overlay which uses such kind of ranged depends extensively. Thanks!
Actual tree layout: cat $ tree . ├── slotted-lib │ ├── slotted-lib-1.ebuild │ ├── slotted-lib-2.ebuild -> slotted-lib-1.ebuild │ ├── slotted-lib-3.ebuild -> slotted-lib-1.ebuild │ └── slotted-lib-4.ebuild -> slotted-lib-1.ebuild └── user └── user-1.ebuild cat $ cat slotted-lib/slotted-lib-1.ebuild EAPI=5 SLOT="${PV}/${PV}" DEPEND= RDEPEND= KEYWORDS="amd64 x86" cat $ cat user/user-1.ebuild EAPI=5 SLOT=0 # allow slots :2 and :3 for slotted-lib # Let's see what vdb entry will get ':=' expanded to RDEPEND=">=${CATEGORY}/slotted-lib-2:= <${CATEGORY}/slotted-lib-4:=" KEYWORDS="amd64 x86"
Information about what causes a rebuild has been added in bug 472104. Your rebuild loop might be solved by the patch in bug 486580. I have another patch for that bug that might be required to fix your issue, but this has not yet been committed.
(In reply to Sebastian Luther (few) from comment #2) > Information about what causes a rebuild has been added in bug 472104. Oh, nice to see you working on those nontrivial bits! Thanks! > Your rebuild loop might be solved by the patch in bug 486580. I have another > patch for that bug that might be required to fix your issue, but this has > not yet been committed. Looks like none of issues is fixed (maybe i didn't specify some funny option to see a trigger): # run 1 $ sudo PORTDIR_OVERLAY="$(pwd)" emerge -tvuD1 cat/user [ebuild N ] cat/user-1::bad-slot 0 kB [ebuild N ] cat/slotted-lib-3:3::bad-slot 0 kB Total: 2 packages (2 new), Size of downloads: 0 kB >>> Emerging (1 of 2) cat/slotted-lib-3 from bad-slot >>> Installing (1 of 2) cat/slotted-lib-3 >>> Emerging (2 of 2) cat/user-1 from bad-slot >>> Installing (2 of 2) cat/user-1 # run 2 (or later) $ sudo PORTDIR_OVERLAY="$(pwd)" emerge -tvuD1 cat/user [ebuild rR ] cat/user-1::bad-slot 0 kB >>> Emerging (1 of 1) cat/user-1 from bad-slot >>> Installing (1 of 1) cat/user-1 Still no info, loop in place. $ emerge --version Portage 2.2.7_p30 (default/linux/amd64/13.0, gcc-4.8.2, glibc-2.17, 3.12.0-00048-gbe408cd x86_64) $ git describe --tags v2.2.7-30-g25d15b9
You found another bug. Thank you for this test case.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=dee9512d2ffec94b4a9eb4ece5c8345e86d04d32
(In reply to Sebastian Luther (few) from comment #5) > This is fixed in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=dee9512d2ffec94b4a9eb4ece5c8345e86d04d32 Yeah, seems to work! Thank you!
Released in sys-apps/portage-2.2.8.
