question on package migration from kde overlay to main tree

[genterminl]

I'm using the portage overlay, and it appears that a number of packages have been migrated from the overlay to the main portage tree. (I assume this is done as they get sufficiently stable.) While this is not itself a problem, it does cause lots of lines in "eix-test-obsolete" under "Installed packages with a version not in the database (or masked):" and also other sections. I don't know whether or not to assume that the ebuild was just moved (possibly with change of stability) or if there were other changes. In either case, what's the best/easiest way to tell portage to either 1) pretend that it really is the one from the tree and not the one no longer in the overlay which is actually installed, or 2) install all of these packages from the main tree?

Thanks for any suggestions.

[asturm]

It would seem wrong for eix to declare them obsolete. Can you give an example? My advice would be to simply ignore eix - with the next version bump of the in-tree packages they would be 'un-'obsoleted. A rebuild with --newrepo is simply wasted CPU time. However if you are still using the kde overlay this will happen on a permanent rate because most version bumps are introduced to kde overlay first, then moved to tree afterwards.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

[genterminl]

I don't think it's declaring them obsolete, just saying the installed version is no longer in the database. (or am I just playing with words tehre?) OK, one example.

[asturm]

16.04.3 was never stable in KDE overlay, that only happens in tree.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

[genterminl]

OK - I misinterpreted the lack of ~ in the installed version as it having been stable.
So is it emerge or just eix that remembers that the current version was installed from the overlay and not from the main tree? If it's eix, then I agree, there is nothing for me to do but wait for the next upgrade in the main tree. (I suppose I could file an enhancement request against eix, but I don't think it's that important.) If it's emerge, then I still wonder if there is a way to tell it update where it thinks it was installed from, or might that be an appropriate enhancement request?

[asturm]

Well, of course the information about the source of an ebuild is stored by Portage:

[genterminl]

Thanks. I've been using eix a lot, so I'm real rusty on many of emerge and equery commands and options. So, portage does know spectacle was installed from the kde overlay, and is currently present in the main tree but not the overlay (for the specific version I have installed). I just haven't found one command to get all of that at once. It just looks like eix is "louder" (for lack of a better word) at pointing out that a package is no longer available in the tree/overlay where it was installed from, but is available elsewhere. /var/db/pkg/${CATEGORY}/${P}/${P}.ebuild can also let you check that it's exactly the same ebuild in the new location.
It looks like the main difference is that portage itself doesn't really care about this situation, but eix makes it more obvious.
I'm still left with my original question, but I now realize it is more aesthetic, and not functional.

As you pointed out in your first reply, "emerge --newrepo" would reinstall all these packages. My working question now is whether I can find some combination of additional emerge options which will update the ...../repository in /var/db/pkg without actually reinstalling the packages. I've tried a bit, and haven't found the right combination yet.

[Josef.95]