On Wed, 2020-03-18 at 12:47 -0500, William Hubbs 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. > > Currently I don't know of any arch/package combos to test this with.
I'm talking about repoman/pkgcheck. > > 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. > Would you CC all arch teams on the bug then? We have ALLARCHES already, and to my experience most arch teams fail to handle that. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
