On Thu, Mar 19, 2020 at 9:47 AM Alec Warner <anta...@gentoo.org> wrote:
> On Thu, Mar 19, 2020 at 6:52 AM Gerion Entrup <gerion.ent...@flump.de> > wrote: > >> Am Donnerstag, 19. März 2020, 02:59:56 CET schrieb Kent Fredric: >> > On Wed, 18 Mar 2020 17:52:25 +0000 >> > James Le Cuirot <ch...@gentoo.org> wrote: >> > >> > > Not quite. Tools like repoman will need to be updated to understand >> > > that an ebuild with KEYWORDS="amd64" can depend on another ebuild with >> > > only KEYWORDS="noarch". I do think the idea has merit though. >> > >> > But the inverse is _not_ true, an ebuild with KEYWORDS="noarch" >> > *cannot* depend on another ebuild with only KEYWORDS="amd64". >> Maybe I misunderstand something but shouldn't that be the normal case? >> Every single Python package (candidates for noarch) for example depends >> on the Python interpreter, which must have non noarch keywords. >> >> >> > Otherwise it breaks the entire stabilization graph. >> The condition would be: If the interpreter is stable for an arch, all >> it's interpreted code is also stable for this arch. >> > > Much of the concern is that this condition is not true for all interpreted > code. > > -A > > >> >> >> Best, >> Gerion >> > If noarch is an alias that includes all keywords, KEYWORDS="noarch -sparc" works (in Portage, not sure what PMS says about keyword additivity) and doesn't break your keyword dependency graph for a Python package that for whatever reason doesn't function on sparc. Semantically, noarch says it hasn't been tested on any arch, so Kent's evidence follows. Once you get a negative test result from an arch, you add -arch to that package. It's not called "allarches".
