View previous topic :: View next topic |
Author |
Message |
genterminl Guru


Joined: 12 Feb 2005 Posts: 505 Location: Connecticut, USA
|
Posted: Fri Aug 12, 2016 4:13 pm Post subject: question on package migration from kde overlay to main tree |
|
|
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. |
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 8055 Location: Austria
|
Posted: Fri Aug 12, 2016 4:46 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
genterminl Guru


Joined: 12 Feb 2005 Posts: 505 Location: Connecticut, USA
|
Posted: Fri Aug 12, 2016 5:52 pm Post subject: |
|
|
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. eix-test-obsolete: | Redundant in /etc/portage/package.{,accept_}keywords:
... considered as REDUNDANT_IF_NO_CHANGE
...
[?] kde-apps/spectacle (16.04.3(5)[1]@07/12/2016 -> (~)16.04.3(5)): Screenshot capture utility
...
...
Installed packages with a version not in the database (or masked):
...
[?] kde-apps/spectacle (16.04.3(5)[1]@07/12/2016 -> (~)16.04.3(5)): Screenshot capture utility | The [1] is for the kde overlay, so it was marked stable in the overlay when I emerged it, but now it's unstable in the main tree. (I do have it in package.keywords.)
I certainly wont bother to re-emerge, agreeing it would just be wasted CPU cycles. However, I'm likely now to stick with whatever version is in the main tree, and eventually migrate away from needing the overlay. Yes, I can just wait for the next version bump in the main tree, and upgrade then, but it would be nice if there were a way for me to tell portage to think that's in fact the version which is currently installed. |
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 8055 Location: Austria
|
Posted: Fri Aug 12, 2016 5:56 pm Post subject: |
|
|
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 |
|
Back to top |
|
 |
genterminl Guru


Joined: 12 Feb 2005 Posts: 505 Location: Connecticut, USA
|
Posted: Fri Aug 12, 2016 6:11 pm Post subject: |
|
|
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? |
|
Back to top |
|
 |
asturm Developer


Joined: 05 Apr 2007 Posts: 8055 Location: Austria
|
Posted: Fri Aug 12, 2016 6:17 pm Post subject: |
|
|
Well, of course the information about the source of an ebuild is stored by Portage:
Code: | /var/db/pkg/${CATEGORY}/${P}/repository |
If you use emerge with --verbose it will show you a possible change of repository appended to the package version information using e.g. ::kde or ::gentoo.
eix is obviously interpreting the information in its own way (I don't use it btw). I have installed kwin-5.7.3 when it was in kde overlay, but using `equery l -iop kwin` I get the following output which makes sense:
Code: | [-P-] [ ] kde-plasma/kwin-5.6.5-r1:5
[IP-] [ ] kde-plasma/kwin-5.7.3:5
[--O] [ -] kde-plasma/kwin-5.7.49.9999:5
[--O] [ -] kde-plasma/kwin-9999:5 |
_________________ backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
Back to top |
|
 |
genterminl Guru


Joined: 12 Feb 2005 Posts: 505 Location: Connecticut, USA
|
Posted: Fri Aug 12, 2016 9:07 pm Post subject: |
|
|
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. |
|
Back to top |
|
 |
Josef.95 Advocate

Joined: 03 Sep 2007 Posts: 3930 Location: Germany
|
Posted: Fri Aug 12, 2016 10:26 pm Post subject: |
|
|
genterminl wrote: | [...] exactly the same ebuild in the new location. [...] | Yes, but the same ebuild guaranteed not the same build - note the eclasses may have changed.
I think a rebuild via --newrepo is the best option. |
|
Back to top |
|
 |
|