| View previous topic :: View next topic |
| Author |
Message |
gjy0724
Apprentice
Joined: 11 Jun 2005
Posts: 165
Location: Lock Haven, Pennsylvania
|
 Posted: Thu Nov 25, 2021 12:51 pm Post subject: General portage question |
 |
|
Let me preface this by saying that I have been using Gentoo for a long time, but I haven't really put much thought into my question before just recently. Suffice to say I am probably using this wrong.
Say I have a package such as dev-python/backrefs which currently only shows version 5.2 and it happens to be stable...yet, I currently have version 5.1 installed which was marked as testing last I checked. For portage, I setup the ~amd64 accepted key word for portage like so...
| Code: | | =dev-python/backrefs-5.1 ~amd64 |
My thinking is that when the next stable build arrives, no matter which version it is, it would be installed as long as it is different than the current version. Yet that doesn't happen, however if I change it to...
| Code: | | dev-python/backrefs ~amd64 |
the next stable build will be installed. Is that why...
| Code: | | >=dev-python/backrefs-5.1 ~amd64 |
is recommended when dealing with testing packages? And as a followup, will that install any package that is in testing or stable?
Thanks in advance and Happy Thanksgiving! |
|
| Back to top |
|
 |
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30908
Location: here
|
| Posted: Thu Nov 25, 2021 1:07 pm Post subject: Re: General portage question |
|
|
| gjy0724 wrote: | | Code: | | =dev-python/backrefs-5.1 ~amd64 |
My thinking is that when the next stable build arrives, no matter which version it is, it would be installed as long as it is different than the current version Yet that doesn't happen |
This is true and is weird that portage not install the next stable version.
For example with sys-apps/less
| Code: | # eix less
[I] sys-apps/less
Available versions: 581.2 ~589 590 {pcre unicode}
Installed versions: 590(04:46:45 PM 09/01/2021)(pcre unicode)
Homepage: http://www.greenwoodsoftware.com/less/
Description: Excellent text file viewer
# echo '=sys-apps/less-589 ~amd64' >> /etc/portage/package.accept_keywords
# emerge -1 '=sys-apps/less-589'
These are the packages that would be merged, in order:
Calculating dependencies ... done!
[ebuild UD~] sys-apps/less-589::gentoo [590::gentoo] USE="pcre unicode" 345 KiB
Total: 1 package (1 downgrade), Size of downloads: 345 KiB
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-apps/less-589::gentoo
>>> Installing (1 of 1) sys-apps/less-589::gentoo
>>> Jobs: 1 of 1 complete Load avg: 0.39, 0.26, 0.32
>>> Auto-cleaning packages...
>>> No outdated packages were found on your system.
* GNU info directory index is up-to-date.
# emerge -uDU @world
Password:
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-apps/less-590::gentoo [589::gentoo] USE="pcre unicode" 0 KiB
Total: 1 package (1 upgrade), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No] |
| gjy0724 wrote: | , however if I change it to...
| Code: | | dev-python/backrefs ~amd64 |
the next stable build will be installed. |
This leads me to say that the version you think is stable is actually not.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
gjy0724
Apprentice
Joined: 11 Jun 2005
Posts: 165
Location: Lock Haven, Pennsylvania
|
| Posted: Thu Nov 25, 2021 1:25 pm Post subject: |
|
|
So, you were able to downgrade the sys-apps/less package to a testing release and then upgrade it back to a stable release using the | Code: | | =sys-apps/less-589 ~amd64 |
syntax, yet this morning I wasn't able to update dev-python/backrefs until I revised my accept_keywords file to | Code: | | dev-python/backrefs ~amd64 |
. And, you are right the last config more likely installs the next version available if it is stable or testing, but obviously the latter is more likely.
With all that said, what is the best way to setup accept_keywords to minimize testing packages. I was hoping | Code: | | =dev-python/backrefs-5.1 ~amd64 |
would do the trick, but it does not. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21624
|
| Posted: Thu Nov 25, 2021 4:53 pm Post subject: |
|
|
| gjy0724 wrote: | | yet this morning I wasn't able to update dev-python/backrefs until I revised my accept_keywords |
Please show the full shell output of what you tried and what Portage printed, both before and after your change to accept_keywords. If I were to guess based on your description, your problem is only related to unstable by way of use flag masking. Consider, on a stable system: | Code: | # emerge -pvO backrefs
These are the packages that would be merged, in order:
[ebuild N ] dev-python/backrefs-5.0.1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_9 (-python3_10) -python3_8" 4024 KiB
Total: 1 package (1 new), Size of downloads: 4024 KiB
# ACCEPT_KEYWORDS=~amd64 emerge -pvO =backrefs-5.0.1
These are the packages that would be merged, in order:
[ebuild N ] dev-python/backrefs-5.0.1::gentoo USE="-doc -test" PYTHON_TARGETS="python3_9 -python3_10 -python3_8" 4024 KiB |
I deliberately forced the same version of the package both with and without unstable keywords. Yet, when I allow unstable keywords, I have the option of using Python 3.10. When I do not allow unstable, python3_10 is masked out (via a use.stable.mask entry in my architecture's profile). My guess is you experienced the same, and your real problem was that you were required to have Python 3.10 support enabled, which was only possible when the unstable keyword overrode the use.stable.mask. | gjy0724 wrote: | With all that said, what is the best way to setup accept_keywords to minimize testing packages. I was hoping | Code: | | =dev-python/backrefs-5.1 ~amd64 |
would do the trick, but it does not. |
You should usually use ~, not =, so that you can accept Gentoo revisions within an upstream release. Other than that, what you describe is reasonable. |
|
| Back to top |
|
|
gjy0724
Apprentice
Joined: 11 Jun 2005
Posts: 165
Location: Lock Haven, Pennsylvania
|
| Posted: Fri Nov 26, 2021 1:26 am Post subject: |
|
|
Let me back up a bit actually. A few weeks ago, I went through all of my ~amd64 entries to try to minimize the number of perpetual test builds by setting all to... | Code: | | =group/package-version ~amd64 |
Although, I knew that some such as packages from overlays, would need to be set to... | Code: | | group/package ~amd64 |
My thought/hope was that using the former testing setting would be that the current testing version would be replaced by the next stable version. I ran updates as normal at least once a week with those settings. However, during a recent update, my Cinnamon desktop broke due to a partial update as I install it from an overlay. So last night I updated all entries from that overlay to use the | Code: | | group/package ~amd64 |
setup which resolved my issue for just those packages and fixed the Cinnamon desktop, none of the other testing packages were updated. Because of that, this morning I went through and did the same to my other testing settings ran a system update | Code: | | emerge -uNDav world |
as normal. Several, somewhere between 5-10 packages were updated including the previously mentioned dev-python/backrefs-5.1 which was testing at install to 5.2 which is a stable, and only listed package on packages.g.o, package. So naturally the changes I made a few weeks ago didn't work like I hoped or thought they would.
Honestly, I do not remember the reason why dev-python/backrefs-5.1 was installed using ~amd64. I need to start adding notes to those files when when making those changes. I do know that the use of python 3.10 was not involved as part of the reason, likely it was because of another package that required it. I mainly brought up that package because it validated that the use of accepted keywords doesn't work like I was hoping for.n
Hopefully that clears up my issue(s). Tonight I went through all of my testing packages and remove the testing references for any that were on stable releases. In the end, I would hope that there was an easier way to handle that scenario.
Thank you |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9527
Location: beyond the rim
|
| Posted: Fri Nov 26, 2021 10:05 am Post subject: |
|
|
You can always check why a certain package version is not installed by running
| Code: | | emerge -p =cat/pkg-version |
That should output an error specifying why that version cannot be installed currently. Alternatively if that command does propose to install the requested version, a deeper investigation might be necessary. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
