| 1 |
Il 07/02/2018 05:11, Duncan ha scritto: |
| 2 |
> AFAIK, (plain) etc-portage semantics are the same for both files -- that |
| 3 |
> is, /etc/portage/package.keywords and the newer package.accept_keywords |
| 4 |
> are identical. |
| 5 |
> |
| 6 |
> The reason for the new name and deprecation of the old one was that |
| 7 |
> package.keywords also exists in the /profile/, where the semantics are |
| 8 |
> different, which created confusion for devs and others attempting to edit |
| 9 |
> the profile version as well as the more commonly user-edited (plain) |
| 10 |
> /etc/portage version. |
| 11 |
> |
| 12 |
> (I add the parenthesized "(plain)" because there's also the deeper |
| 13 |
> /etc/portage/profile path, which takes profile changes and therefore the |
| 14 |
> profile format. Actually, I suspect it was someone editing that using |
| 15 |
> the wrong format and then filing a bug when things didn't work as |
| 16 |
> expected that likely prompted the new name and deprecation of the old |
| 17 |
> one.) |
| 18 |
|
| 19 |
Ok, thank you for the information, it's very interesting. |
| 20 |
I may need to update my solver then :) (I thought that *.keywords always manipulated the KEYWORDS variable, while *.accept_keywords manipulated the ACCEPT_KEYWORDS). |
| 21 |
|
| 22 |
> I've a rather unusual portage config here: |
| 23 |
> |
| 24 |
> * /etc/portage/profile/packages contains a -* entry, negating the entire |
| 25 |
> normal @system set. Many normally @system packages I really need are |
| 26 |
> dependencies of something or other I already have in @world anyway, and |
| 27 |
> I've added @world entries where necessary to keep the few exceptions |
| 28 |
> installed. |
| 29 |
> |
| 30 |
> * My USE starts with a -* entry as well, negating profile and package USE |
| 31 |
> defaults so I have direct control of all USE flag settings and don't have |
| 32 |
> to worry about USE flag changes on profile updates or tracking down why a |
| 33 |
> flag is changing when I didn't change anything, both previous problems I |
| 34 |
> had to deal with until I set that initial -*, so the only flags set are |
| 35 |
> the ones I deliberately chose, myself. |
| 36 |
|
| 37 |
Does the -* also remove profile USE defaults for USE flags in PROFILE_ONLY_VARIABLES? |
| 38 |
My understanding is that only files in a profile (either /etc/portage/make.profile or /etc/portage/profile) can configure these USE flags. |
| 39 |
|
| 40 |
> * My world file (/var/lib/portage/world) is empty. I've categorized |
| 41 |
> everything into individual sets found in /etc/portage/sets, with those in |
| 42 |
> turn listed in the world_sets file (/var/lib/portage/world_sets). |
| 43 |
|
| 44 |
Interesting, I didn't know about the /var/lib/portage/world_sets file (it escaped me somehow). |
| 45 |
I currently include in all the packages listed in the /etc/portage/sets/* files. |
| 46 |
It can be fixed easily. |
| 47 |
|
| 48 |
> * Overlays... (Less unusual, but still not mainline...) I run nearly all |
| 49 |
> the kde I have installed (frameworks/plasma/apps), as well as a few other |
| 50 |
> packages, from the live-git *-9999 packages found in the gentoo/kde |
| 51 |
> overlay (and others). Package keywording/masking is adjusted |
| 52 |
> accordingly. (Everything else is mainline ~amd64.) |
| 53 |
> |
| 54 |
> I expect one or more of these you won't have anticipated so they'll |
| 55 |
> present a challenge for your current script, but because it /is/ a rather |
| 56 |
> unusual setup, I'm not sure it's worth your trouble to bother with. |
| 57 |
|
| 58 |
Out of all your points, only the overlays are not managed by our solver. |
| 59 |
As your setup is unusual, apar from the overlay, it could be a good test case for our tool to check the configuration loading. |
| 60 |
Right now in my tests, I deal with overlay by adding manually all the installed packages that is missing from the base portage tree... |
| 61 |
If there is not too much packages to add (I guess 50 is still ok, 100 is a bit too much). |
| 62 |
|
| 63 |
> OTOH, if you want unusual corner-cases to test... |
| 64 |
|
| 65 |
I'm from formal methods, focused on correction and completeness... |
| 66 |
So yes, corner cases are important and interesting, and are useful to detect early bug or design errors. |
| 67 |
|
| 68 |
> So bother sending the results in (you're ready for it already), or you |
| 69 |
> want them, but wait until you've adjusted the script to deal with it, or |
| 70 |
> don't bother, you're not going to try supporting anything that unusual |
| 71 |
> anyway? |
| 72 |
|
| 73 |
Send it in :). |
| 74 |
If I have problems with it, I may not fix the bugs right away, but at least I would know about it. |
| 75 |
|
| 76 |
Thanks, |
| 77 |
Michael Lienhardt |
Archives