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 |