Hi,
I'd be in support. Especially for "data only" kind of packages, like:
net-misc/asterisk-moh-opsound
net-misc/asterisk-extra-sounds
net-misc/asterisk-core-sounds
For all three these I've already dropped the DEPEND on net-misc/asterisk
anyway, and upgraded the PDEPEND on net-misc/asterisk back onto these to
RDEPEND. Other than that they really only install a bunch of audio
files in various formats.
One could even mark the various acct-{user,group}/* packages this way
(although this is a simple eclass change).
One challenge I foresee is that one could have a perl, python or php
(script language of choice) package depend on a specific version of
interpreter, which may not be stable for given arch. So may require
some special handling in terms of dependencies.
Kind Regards,
Jaco
On 2020/03/18 16:54, William Hubbs wrote:
> All,
>
> 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.
>
> Thanks,
>
> William
>
