From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id A0ADB1382C5 for ; Wed, 7 Feb 2018 04:14:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3D63E0A45; Wed, 7 Feb 2018 04:13:55 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 41520E0935 for ; Wed, 7 Feb 2018 04:13:55 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ejH50-0006JX-4p for gentoo-dev@lists.gentoo.org; Wed, 07 Feb 2018 05:11:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: SAT-based dependency solver: request for test cases Date: Wed, 7 Feb 2018 04:11:00 +0000 (UTC) Message-ID: References: <32e87315-cf63-8dca-4490-292afa56b28b@laposte.net> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Pan/0.145 (Duplicitous mercenary valetism; 27bc4e90f) X-Archives-Salt: 6d04e75f-b9fa-41eb-9236-074a7a730e0d X-Archives-Hash: de511d50b562405cf87bae74b41e92c8 Michael Lienhardt posted on Tue, 06 Feb 2018 23:53:05 +0100 as excerpted: > Il 06/02/2018 15:00, Roy Bamford ha scritto: >> Posting here to alert other potential helpers. >> Your script uses >> >> PACKAGE_KEYWORDS="/etc/portage/package.accept_keywords" >> >> but thats a recent name change. >> >> PACKAGE_KEYWORDS="/etc/portage/package.keywords" >> >> is the old name and my older systems still use that. >> You probably need to harvest both and process both as portage does. > > You are right, I was lazy (and hoped that everyone already made the > switch because, as I understand it, package.keywords and > package.accept_keywords do not have the same semantics). > I added the package.keywords file/folder in the script. 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.) Meanwhile... 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. * 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). * 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. OTOH, if you want unusual corner-cases to test... 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? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman