Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: SAT-based dependency solver: request for test cases
Date: Wed, 07 Feb 2018 04:14:02
Message-Id: pan$3bd3e$dc887f8a$4805e05b$58061d3b@cox.net
In Reply to: Re: [gentoo-dev] SAT-based dependency solver: request for test cases by Michael Lienhardt
1 Michael Lienhardt posted on Tue, 06 Feb 2018 23:53:05 +0100 as excerpted:
2
3 > Il 06/02/2018 15:00, Roy Bamford ha scritto:
4 >> Posting here to alert other potential helpers.
5 >> Your script uses
6 >>
7 >> PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords"
8 >>
9 >> but thats a recent name change.
10 >>
11 >> PACKAGE_KEYWORDS="/etc/portage/package.keywords"
12 >>
13 >> is the old name and my older systems still use that.
14 >> You probably need to harvest both and process both as portage does.
15 >
16 > You are right, I was lazy (and hoped that everyone already made the
17 > switch because, as I understand it, package.keywords and
18 > package.accept_keywords do not have the same semantics).
19 > I added the package.keywords file/folder in the script.
20
21 AFAIK, (plain) etc-portage semantics are the same for both files -- that
22 is, /etc/portage/package.keywords and the newer package.accept_keywords
23 are identical.
24
25 The reason for the new name and deprecation of the old one was that
26 package.keywords also exists in the /profile/, where the semantics are
27 different, which created confusion for devs and others attempting to edit
28 the profile version as well as the more commonly user-edited (plain)
29 /etc/portage version.
30
31 (I add the parenthesized "(plain)" because there's also the deeper
32 /etc/portage/profile path, which takes profile changes and therefore the
33 profile format. Actually, I suspect it was someone editing that using
34 the wrong format and then filing a bug when things didn't work as
35 expected that likely prompted the new name and deprecation of the old
36 one.)
37
38
39 Meanwhile...
40
41 I've a rather unusual portage config here:
42
43 * /etc/portage/profile/packages contains a -* entry, negating the entire
44 normal @system set. Many normally @system packages I really need are
45 dependencies of something or other I already have in @world anyway, and
46 I've added @world entries where necessary to keep the few exceptions
47 installed.
48
49 * My USE starts with a -* entry as well, negating profile and package USE
50 defaults so I have direct control of all USE flag settings and don't have
51 to worry about USE flag changes on profile updates or tracking down why a
52 flag is changing when I didn't change anything, both previous problems I
53 had to deal with until I set that initial -*, so the only flags set are
54 the ones I deliberately chose, myself.
55
56 * My world file (/var/lib/portage/world) is empty. I've categorized
57 everything into individual sets found in /etc/portage/sets, with those in
58 turn listed in the world_sets file (/var/lib/portage/world_sets).
59
60 * Overlays... (Less unusual, but still not mainline...) I run nearly all
61 the kde I have installed (frameworks/plasma/apps), as well as a few other
62 packages, from the live-git *-9999 packages found in the gentoo/kde
63 overlay (and others). Package keywording/masking is adjusted
64 accordingly. (Everything else is mainline ~amd64.)
65
66 I expect one or more of these you won't have anticipated so they'll
67 present a challenge for your current script, but because it /is/ a rather
68 unusual setup, I'm not sure it's worth your trouble to bother with.
69
70 OTOH, if you want unusual corner-cases to test...
71
72 So bother sending the results in (you're ready for it already), or you
73 want them, but wait until you've adjusted the script to deal with it, or
74 don't bother, you're not going to try supporting anything that unusual
75 anyway?
76
77 --
78 Duncan - List replies preferred. No HTML msgs.
79 "Every nonfree program has a lord, a master --
80 and if you use the program, he is your master." Richard Stallman

Replies

Subject Author
Re: [gentoo-dev] Re: SAT-based dependency solver: request for test cases Michael Lienhardt <michael.lienhardt@×××××××.net>