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