| View previous topic :: View next topic |
| Author |
Message |
Valfar
n00b
Joined: 27 Feb 2018
Posts: 3
|
 Posted: Tue Feb 27, 2018 4:07 am Post subject: alternative to ACCEPT_KEYWORDS with prioritization...? |
 |
|
I'm actually a longtime Gentoo user (since 2003ish), but had to make a new account due to my forum email address being long-since defunct...
Anyway, I'm noticing my package.accept_keywords file growing ever-longer lately. I know that I created a lot of those entries because they were ~arch dependencies of various ~arch packages, which I've needed when I ran across bugs in a stable package that were already fixed in unstable. My package.accept_keywords is now 205 lines, and I'd like it to not be.
It's also rather annoying to keyword a package ~arch (to fix a known bug), try to emerge it, then have emerge barf on its 3 dependencies that also need to be ~arch, then keyword those, then have emerge barf again because of all their ~arch dependencies, etc... I mean, the entire point of having a package manager is to prevent having to manually deal with "dependency hell", right?
So here's my question: is there a way to set up portage with some kind of priority on ACCEPT_KEYWORDS entries? Maybe similar to what APT pinning can do...? The logic I need is this:
* If a dependency (of either a package to be installed or already installed) can be satisfied with a version keyworded stable, use that (stable) version.
* If a dependency cannot be satisfied with any version keyworded stable, but could be satistified with a version keyworded unstable, use that (unstable) version.
* Otherwise: return error.
Or in other words: "accept both stable and unstable keywords, but prefer stable keywords when all dependencies can be satisfied". I've run full ~arch before, but that's not really a great solution either: it brings in tons of unstable packages that I don't actually need the unstable version of.
Is there any way to accomplish what I want with current portage? Maybe some bashrc hack, or feature I'm not aware of...?
Thanks in advance. |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Feb 27, 2018 5:22 am Post subject: |
|
|
This isn't really what you're asking for, but if no better solutions come along...
Do you specify versions to allow, or do you allow any version?
I've found specific versions or ranges (gentoo-sources-4.14*) to be much easier to manage, but I try keeping them to a minimum.
At some point I added "=dev-python/cryptography-1.7.2 ~amd64." I now have "stable" version 2.02.-r1. On another system, I had set ~amd64 for lumina-1.2.0. Now lumina-1.3.0_p1 is stable. Without any additional work on my part other than periodic cleaning of stale entries.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Valfar
n00b
Joined: 27 Feb 2018
Posts: 3
|
| Posted: Tue Feb 27, 2018 5:44 am Post subject: |
|
|
| pjp wrote: | Do you specify versions to allow, or do you allow any version?
I've found specific versions or ranges (gentoo-sources-4.14*) to be much easier to manage, but I try keeping them to a minimum.
|
The package atoms I use have no version/slot specified, unless they are necessary for the match to actually work as intended. I know that emerge's autounmask feature likes to keyword only the one version to be installed... but I find that this tends to cause further problems later on, after the unstable version gets bumped and stops matching the existing entry. I'd rather over-keyword for unstable than have "surprise downgrades" which I may or may not notice before they occur :/
i.e. foo/bar-1.2.1 is stable, but I run into a bug and need >=foo/bar-1.3.0 which is unstable at the time.
If I keyword =foo/bar-1.3.0, and then foo/bar-1.3.1 comes out.... portage won't upgrade me to 1.3.1, even though that's probably a good idea if I'm already running 1.3.0.
If I keyword =foo/bar-1.3.0, foo/bar-1.3.1 comes out, and the foo/bar-1.3.0 ebuild is removed... portage will probably wind up wanting to downgrade me to foo/bar-1.2.1 at some point. If I don't notice this before accepting the emerge then I wind up with the same bug resurfacing (not cool and very frustrating). On top of that, the downgrade from 1.3.x to 1.2.x might bring other fun consequences with it.
If I keyword =foo/bar-1.3*... then foo/bar-1.3.X upgrades work OK, but foo/bar-1.4 and beyond trigger all of the same shenanigans (assuming stable sticks with foo/bar-1.2.X throughout - which is the sort of situation I see often)
If I keyword >=foo/bar-1.3.0... then I might as well have just keyworded "foo/bar" instead...
This becomes extra fun when multiple machines are involved. I have 7-10 Gentoo installs at home; I actively use about 3-5 of them. They share most (but not all) of /etc/portage via NFS with some symlink tricks. Once I've solved this type of issue on one machine, I'd prefer to not encounter it again on any of the others. This means the entries I put in /etc/portage - which are usually going into a file pulled in by all machines - need to still work as intended for the inactive machines' next world update, which might be 6-12 months in the future. Over-keywording does okay in this respect.
If there was a way to tell portage what I really wanted, i.e. "I need >=foo/bar-1.3, >=foo/baz-1.4.2, and <foo/quux-2.1"... and then have portage figure out which ~arch dependencies are actually necessary to make that happen, without needing anything further in package.* to let those dependencies get merged... then I'd be a lot happier about the situation. I bet that would cut my package.accept_keywords from 205 lines down to 15-20 or so, and only a handful of additional dependencies would be pulled from ~arch. That would be totally reasonable and manageable.
I'm aware I could split package.accept_keywords into two files - one containing the leaf packages, of which I need specific versions to avoid bugs; the other to soak up all their ~arch dependencies. I already do something similar for package.use. The issue here is that it's still not easy to prune the "dependencies" part of package.accept_keywords. It would be pretty much trial and error... comment one line out, try to remerge world, see if the depgraph breaks; repeat for many painful hours. Yes, that could probably be automated, but doing so definitely seems like the wrong solution - it should be entirely possible for portage to deal with this itself. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Tue Feb 27, 2018 4:15 pm Post subject: |
|
|
| pjp wrote: |
At some point I added "=dev-python/cryptography-1.7.2 ~amd64." I now have "stable" version 2.02.-r1. On another system, I had set ~amd64 for lumina-1.2.0. Now lumina-1.3.0_p1 is stable. Without any additional work on my part other than periodic cleaning of stale entries. |
I run pretty much this same way, except I don't get around to cleaning stale entries nearly often enough. Do you know of a tool to help with this task?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Tue Feb 27, 2018 4:32 pm Post subject: |
|
|
| portpeek |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10589
Location: Somewhere over Atlanta, Georgia
|
| Posted: Tue Feb 27, 2018 4:46 pm Post subject: Re: alternative to ACCEPT_KEYWORDS with prioritization...? |
|
|
| Valfar wrote: | | I'm actually a longtime Gentoo user (since 2003ish), but had to make a new account due to my forum email address being long-since defunct... |
We can recover this account if you know the user name and we can establish that it's really you.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Tue Feb 27, 2018 4:49 pm Post subject: |
|
|
| depontius wrote: |
I run pretty much this same way, except I don't get around to cleaning stale entries nearly often enough. Do you know of a tool to help with this task? |
eix-test-obsolete |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30922
Location: here
|
| Posted: Tue Feb 27, 2018 5:19 pm Post subject: |
|
|
+1
I discovered this tool only one month ago and work very well
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Feb 27, 2018 5:27 pm Post subject: |
|
|
Excellent, thank you.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Valfar
n00b
Joined: 27 Feb 2018
Posts: 3
|
| Posted: Tue Feb 27, 2018 10:27 pm Post subject: |
|
|
I definitely wasn't aware of this tool; kudos for the tip.
Unfortunately, it doesn't help too much in my case... It's definitely detecting entries in package.* that are no longer relevant (packages not even installed, old obsolete USE-flags being set, etc). But due to me not putting version restrictions on most of package.accept_keywords, the tool isn't really able to help re: pruning ~arch keywords in cases where I don't actually need ~arch anymore.
| Tony0945 wrote: | | eix-test-obsolete |
| Code: | % man eix-test-obsolete
No manual entry for eix-test-obsolete
% eix-test-obsolete --help
/usr/bin/eix-test-obsolete: illegal option -- -
% eix-test-obsolete -h
[yay, meaningful help output!]
% eix-test-obsolete brief
[gigantic spew to terminal]
% eix-test-obsolete brief 2>&1 | wc -l
20626
|
That's "brief"? Dear lord.
| John R. Graham wrote: | | We can recover this account |
YGPM |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Feb 28, 2018 7:12 am Post subject: |
|
|
| Valfar wrote: | | That's "brief"? |
"brief" means that it doesn't fine-tune the reason why a package is listed (perhaps the option should have been called "semi-quick" instead of "brief", although the output is also somewhat shorter if there are several reasons why a package appears). Most likely, this is not what you want if you intend to clean up. It is mainly useful if you have already cleaned up and want to verify after a fresh syncing that nothing else appears in the list.
There is the problem that people consider different things as redundant. For instance, if you masked a package for which no version is actually installed, this mask is redundant (because it might be removed without changing the next portage output). The default is such that if in doubt the package is listed.
You can surpress/modify certain reasons globally by setting REDUNDANT_IF_* (or perhaps even NONEXISTENT_IF_*) variables in /etc/eixrc.
You can also list intentional exceptions (for individual packages, e.g. for masks which you want to have although no version is installed) in /etc/portage/package.nowarn/ with an appropriate keyword. See the eix manpage for details. |
|
| 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
