On Wed, Mar 18, 2020 at 05:52:25PM +0000, James Le Cuirot wrote: > On Wed, 18 Mar 2020 12:47:53 -0500 > William Hubbs <willi...@gentoo.org> wrote: > > > On Wed, Mar 18, 2020 at 06:12:37PM +0100, Michał Górny wrote: > > > On Wed, 2020-03-18 at 09:54 -0500, William Hubbs wrote: > > > > this came up again on the recent thread about dropping non x86/amd64 > > > > support for python packages, and I want to bring it up again on its own > > > > thread. > > > > > > > > How often do architecture specific bugs really exist in languages like > > > > perl, python etc? From what I've seen they are pretty rare. Not to > > > > mention, > > > > if we found one somewhere, we could adjust keywords as necessary. > > > > > > > > Also, if someone did inadvertently keyword a package with noarch that > > > > didn't > > > > work everywhere, it would be a matter of adjusting the keywords for that > > > > package. > > > > > > > > So, my question is, why can't we add a noarch/~noarch keyword and see > > > > how things go? If it gets abused we can always nuke it later. > > > > > > > > > > 1. How is this going to work when noarch package depends on non-nonarch > > > package? I mean, will all the package managers actually work? Have you > > > did some minimal testing before bringing this up? > > > > Can you have multiple ACCEPT_KEYWORDS values in make.conf or > > make.defaults like this? > > > > ACCEPT_KEYWORDS="amd64 noarch" > > > > If so, things should just work. > > 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.
Ok, that's reasonable and generates more questions. How much work would it be to update the tools to take that into account? In the meantime, is it worth adding the noarch keyword but not dropping other keywords until the tools are fixed? William
signature.asc
Description: Digital signature
