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. Currently I don't know of any arch/package combos to test this with. > 2. Who will be responsible for handling noarch stablereqs? Will there > be a noarch arch team? The maintainer would be able to add the "~noarch" keyword. I'm not sure there needs to be a noarch arch team. We could just say that all arch team members can stabilize these or maybe the maintainers can afterh the timeout. William > -- > Best regards, > Michał Górny >
signature.asc
Description: Digital signature
